<?xml version="1.0" encoding="utf-8"?>
<vulnerabilities xmlns="http://tempuri.org/XMLSchemaOptions.xsd">

<vuln_items>wasc_1</vuln_items>
<vuln_item_wasc_1>
	<alert>Autenticação Insuficiente</alert>
	<desc>Autenticação Insuficiente ocorre quando um site ou aplicação web permite que um invasor acesse conteúdo ou funcionalidade confidencial sem a necessidade de se autenticar adequadamente. Ferramentas de administração baseadas na web são bons exemplos de sites que fornecem acesso a funcionalidades confidenciais. Dependendo da especificidade do recurso online, essas aplicações não devem ser acessadas diretamente sem antes exigir que o usuário confirme adequadamente sua identidade.

Para obter as configurações de autenticação, alguns recursos são protegidos de modo a "ocultar" sua localização específica e não vincular a sua localização ao site principal ou a outros locais públicos. No entanto, essa abordagem nada mais é do que "Segurança Por Meio de Obscuridade". É importante entender que, embora um recurso seja desconhecido ou oculto para um invasor, ele ainda permanece acessível diretamente por meio de um URL específico. A URL específica pode ser descoberta por meio de uma sondagem Brute Force para locais comuns de arquivos e diretórios (/admin por exemplo), mensagens de erro, logs de referência ou documentação, como arquivos de ajuda. Esses recursos, sejam eles orientados por conteúdo ou funcionalidade, devem ser protegidos de forma adequada.</desc>
	<solution>Fase: Arquitetura e Design.
Use um framework de autenticação ou uma biblioteca, como o recurso de autenticação OWASP ESAPI.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Authentication</reference>
	<reference>http://cwe.mitre.org/data/definitions/287.html</reference>
	<reference>http://cwe.mitre.org/data/definitions/284.html</reference>
</vuln_item_wasc_1>

<vuln_items>wasc_2</vuln_items>
<vuln_item_wasc_2>
	<alert>Autorização Insuficiente</alert>
	<desc>Autorização Insuficiente ocorre quando um aplicativo não executa adequadamente as verificações de autorização para garantir que o usuário esteja executando uma função ou acessando dados de maneira consistente com as políticas de segurança. Os procedimentos de autorização devem forçar um usuário, serviço ou aplicativo, limitando-o apenas ao que tem permissão para fazer. Quando um usuário é autenticado em um site ou aplicação web, isso não significa necessariamente que deva ter acesso total a todo o conteúdo e funcionalidades.


Autorização de Função Insuficiente:
Muitos aplicativos concedem funcionalidades diferentes a usuários diferentes. Um site de notícias permite que os usuários vejam as notícias, mas não as publiquem. Um sistema de contabilidade terá permissões diferentes entre os contadores de Contas a Pagar e os contadores de Contas a Receber. 
Autorização Insuficiente de Função:
Ocorre quando um aplicativo não impede que os usuários acessem indiscriminadamente as suas funcionalidades, violando as políticas de segurança.

Um exemplo que teve muita visibilidade, foi o hack de 2005 do processo de inscrição da Harvard Business School. Uma falha de autorização permitiu que os usuários visualizassem seus próprios dados, quando não deveriam ter acesso a essa parte do site.
 
Autorização Insuficiente de Dados:
Muitos aplicativos expõem identificadores de dados implícitos em URLs. Por exemplo, ao acessar um prontuário médico em um sistema, pode-se ter um URL como: http://example.com/RecordView?id=12345
Se o aplicativo não verifica que o ID do usuário autenticado tem direitos de leitura, poderá exibir dados para o usuário que ele não deveria ver.

Autorização Insuficiente de Dados é mais comum do que a Autorização Insuficiente de Função porque os desenvolvedores geralmente têm conhecimento completo da funcionalidade do aplicativo, mas nem sempre têm um mapeamento completo de todos os dados que o aplicativo acessará. Geralmente os desenvolvedores têm controle rígido sobre os mecanismos de autorização de função, mas contam com outros sistemas, como bancos de dados, para realizar a autorização de dados.</desc>
	<solution>Fases: Arquitetura e Design | Operação.
Administre com muito cuidado a configuração, o gerenciamento e o tratamento de privilégios. Gerencie de forma explícita as zonas permitidas no software.


Fase: Arquitetura e Design.
Certifique-se de que a apropriada compartimentação esteja incorporada ao design do sistema e que sirva para permitir e reforçar ainda mais a funcionalidade de separação de privilégios. Arquitetos e designers de software devem confiar no princípio do menor privilégio para decidir quando é apropriado usar e descartar os privilégios do sistema.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Authorization</reference>
	<reference>http://cwe.mitre.org/data/definitions/284.html</reference>
	<reference>http://cwe.mitre.org/data/definitions/285.html</reference>
</vuln_item_wasc_2>

<vuln_items>wasc_3</vuln_items>
<vuln_item_wasc_3>
	<alert>Estouro de Número Inteiro</alert>
	<desc>Um Estouro de Número Inteiro é a condição que ocorre quando o resultado de uma operação aritmética, como multiplicação ou adição, excede o tamanho máximo do tipo de número inteiro usado para armazená-lo. Quando ocorre um estouro de número inteiro, o valor interpretado aparece como se tivesse chegado no valor máximo e reiniciado no valor mínimo, semelhante a um relógio que representa 13:00 apontando para 1:00.

Por exemplo, na maioria das arquiteturas de computador, um número inteiro de 8 bits tem um valor máximo de 127 e um valor mínimo de -128. Se um desenvolvedor armazena o valor 127 em tal variável e adiciona 1 a ela, o resultado deveria ser 128. No entanto, este valor excede o máximo para este tipo de número inteiro, portanto, o valor interpretado será “agrupado” e se tornará -128.</desc>
	<solution>Fase: Requisitos.
Certifique-se de que todos os protocolos estejam rigorosamente definidos, de modo que todos os comportamentos fora dos limites ou não-padronizados possam ser identificados de forma simples e exijam conformidade estrita com oos protocolos.


Fase: Requisitos.
Use uma linguagem que não permita que essa vulnerabilidade ocorra ou então forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.
Se possível, escolha uma linguagem ou compilador que execute a verificação automática de limites.


Fase: Arquitetura e Design.
Use uma biblioteca verificada ou framework que não permita que essa vulnerabilidade ocorra, ou forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.
Use bibliotecas ou frameworks que tornem mais fácil lidar com números sem consequências inesperadas.
Inclusos como exemplo, estão os pacotes de manipulação de números inteiros seguros, como SafeInt (C ++) ou IntegerLib (C ou C ++).


Fase: Implementação.
Execute validação de entradas em qualquer input numérico, garantindo que esteja dentro da faixa/limite esperados. Garanta que a entrada atenda aos requisitos mínimo e máximo para a faixa/limite esperados.
Use inteiros sem sinal sempre que possível. Isso torna mais fácil realizar verificações de integridade para estouros de inteiros. Se você necessita usar inteiros com sinal, certifique-se de que sua verificação de intervalo inclui valores mínimos, bem como valores máximos.


Fase: Implementação.
Entenda bem a fundo a sintaxe da representação implícita da sua linguagem de programação e como ela interage com o cálculo numérico (CWE-681). Preste muita atenção às discrepâncias de tamanho de byte, de precisão, de distinções assinadas e não-assinadas, de truncamento, de conversão e fusão entre tipos, de cálculos de valores numéricos indefinidos ou irrepresentáveis (NaN) e de como sua linguagem de programação lida com números que são muito grandes ou muito pequenos para sua representação implícita.
Tome cuidado também ao levar em consideração, representações em 32 bits, 64 bits e outras diferenças potenciais que podem afetar as representações numéricas.


Fase: Implementação.
Examine atentamente os avisos do compilador e elimine problemas potencialmente críticos de segurança, como incompatibilidades assinadas / não-assinadas. Mesmo que a vulnerabilidade raramente seja explorável, uma única falha pode levar ao comprometimento de todo o sistema.</solution>
	<reference>http://projects.webappsec.org/Integer-Overflows</reference>
	<reference>http://cwe.mitre.org/data/definitions/190.html</reference>
</vuln_item_wasc_3>

<vuln_items>wasc_4</vuln_items>
<vuln_item_wasc_4>
	<alert>Proteção Insuficiente na Camada de Transporte</alert>
	<desc>Proteção Insuficiente na Camada de Transporte:
A vulnerabilidade causada por proteção insuficiente na camada de transporte, permite que a comunicação seja exposta a terceiros desconhecidos ou não-confiáveis, fornecendo um vetor de ataque que possibilita comprometer um site ou aplicativo web e/ou roubar informações confidenciais. Geralmente os sites ou aplicações web usam SSL/TLS (Secure Sockets Layer / Transport Layer Security) para fornecer criptografia na camada de transporte. No entanto, a menos que a aplicação web ou site seja configurado para usar SSL/TLS corretamente, ele pode ser vulnerável à interceptação e modificação de tráfego.
 

Falta de Criptografia na Camada de Transporte:
Quando a camada de transporte não está criptografada, toda a comunicação entre o site e o cliente é enviada em texto puro não-criptografado, o que a deixa aberta para interceptação, injeção e redirecionamento (também conhecido como ataque man-in-the-middle/MITM). Um invasor pode interceptar passivamente a comunicação, obtendo acesso a quaisquer dados confidenciais transmitidos, como nomes de usuário e senhas. Um invasor também pode injetar/remover ativamente conteúdos da comunicação, permitindo-o que falsifique e omita informações, insira scripts maliciosos ou faça com que o cliente acesse conteúdo remoto não confiável. Um invasor pode também redirecionar a comunicação de forma que o site e o cliente não se comuniquem mais, mas sem saber, se comuniquem com o invasor achando ser a outra parte confiável da comunicação.


Suporte de Criptografia Fraca:
Historicamente, a criptografia de alto grau era restrita à exportação para fora dos Estados Unidos da América. Por isso, os sites eram configurados para oferecer suporte a opções criptográficas fracas para os clientes que estavam restritos ao uso de criptografia fraca. Cifras fracas são vulneráveis a ataques devido à relativa facilidade de quebrá-las; menos de duas semanas em um computador doméstico típico e alguns segundos usando hardware dedicado.
Atualmente, todos os navegadores e sites modernos usam criptografia muito mais forte, mas alguns sites ainda estão configurados para oferecer suporte a criptografias fracas desatualizadas. Por isso, um invasor pode forçar o cliente a fazer o downgrade para uma criptografia mais fraca ao se conectar ao site, permitindo que posteriormente o invasor quebre a criptografia fraca. Por esse motivo, o servidor deve ser configurado para aceitar apenas criptografias fortes e não fornecer serviço a qualquer cliente que solicite o uso de uma criptografia mais fraca. Além disso, alguns sites são configurados incorretamente para escolher uma criptografia mais fraca, mesmo quando o cliente oferece suporte a uma muito mais forte. O OWASP oferece um guia para testar problemas de SSL/TLS, incluindo suporte a criptografia fraca e configuração incorreta, além de outros recursos e ferramentas.</desc>
	<solution>Fase: Requisitos.
Especifique claramente quais dados ou recursos são valiosos o suficiente para que sejam protegidos por criptografia. Exija que qualquer transmissão ou armazenamento desses dados/recursos use algoritmos de criptografia bem avaliados.


Fase: Arquitetura e Design.
Usando modelagem de ameaças ou outras técnicas, presuma que seus dados sempre possam ser comprometidos por vulnerabilidades ou fraquezas separadas e determine onde a criptografia será mais eficaz. Certifique-se de que os dados que você acredita que deveriam ser privados não sejam expostos inadvertidamente por meio de fraquezas como permissões inseguras (CWE-732).


Fase: Arquitetura e Design.
Certifique-se de que a criptografia esteja devidamente integrada ao design do sistema, incluindo, mas não necessariamente limitado a:
* - Criptografia necessária para armazenar ou transmitir dados privados dos usuários do sistema;
* - Criptografia necessária para proteger o próprio sistema contra divulgação não autorizada ou adulteração.
Identifique as necessidades e contextos separados para criptografia:
* - Uma via (ou seja, apenas o usuário ou destinatário precisa ter a chave). Isso pode ser conseguido usando criptografia de chave pública ou outras técnicas em que a parte criptografadora (ou seja, o software) não precisa ter acesso a uma chave privada;
      * - Bidirecional (ou seja, a criptografia pode ser executada automaticamente em nome de um usuário, mas a chave deve estar disponível para que o texto simples possa ser recuperado automaticamente por esse usuário). Isso requer o armazenamento da chave privada em um formato que pode ser recuperado apenas pelo usuário (ou talvez pelo sistema operacional) de modo que não possa ser recuperada por terceiros.


Fase: Arquitetura e Design.
Não desenvolva seus próprios algoritmos criptográficos. Eles provavelmente serão expostos a ataques que são muito bem compreendidos por criptógrafos. As técnicas de engenharia reversa já estão bem amadurecidas. Se o seu algoritmo pode ser comprometido caso os invasores descubram como ele funciona, então ele é especialmente vulnerável/fraco.


Fase: Arquitetura e Design.
Escolha um algoritmo bem testado que atualmente seja considerado forte por especialistas na área e escolha implementações/construções bem testadas.
Por exemplo, os sistemas do governo dos EUA exigem a certificação FIPS 140-2.
Como ocorre com todos os mecanismos criptográficos, o código-fonte deve estar disponível para análise.
Certifique-se periodicamente de não estar usando criptografia obsoleta. Alguns algoritmos mais antigos, que antes precisavam de um bilhão de anos de tempo de computação, agora podem ser quebrados em dias ou horas. Isso inclui MD4, MD5, SHA1, DES e outros algoritmos que já foram considerados fortes.


Fase: Arquitetura e Design.
Compartimentalize seu sistema para ter áreas "seguras" onde os limites de confiança possam ser definidos de forma inequívoca. Não permita que dados confidenciais saiam do limite de confiança e sempre tenha cuidado ao fazer a interface com um compartimento fora da área segura.


Fases: Implementação | Arquitetura e Design.
Quando usar técnicas aprovadas pelo mercado, você precisa usá-las corretamente. Não tente economizar ignorando etapas que consomem muitos recursos (CWE-325). Essas etapas geralmente são essenciais para prevenir ataques comuns.


Fase: Implementação.
Use convenções de nomenclatura e tipos fortes para tornar mais fácil identificar quando dados confidenciais estão sendo usados. Ao criar estruturas, objetos ou outras entidades complexas, separe os dados confidenciais e não confidenciais o máximo possível.
Isso torna mais fácil encontrar os locais no código onde os dados não criptografados estão sendo usados.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Transport-Layer-Protection</reference>
	<reference>http://cwe.mitre.org/data/definitions/311.html</reference>
</vuln_item_wasc_4>

<vuln_items>wasc_5</vuln_items>
<vuln_item_wasc_5>
	<alert>Inclusão de Arquivo Remoto</alert>
	<desc>Inclusão de Arquivo Remoto (Remote File Include ou RFI) é uma técnica de ataque usada para explorar mecanismos de inclusão de arquivo dinâmico em sites ou aplicativos web. Quando sites ou aplicações web recebem a entrada do usuário (URL, valor de parâmetro, etc.) e os passam para comandos de inclusão de arquivo, o aplicativo da web pode ser enganado para incluir arquivos remotos com código malicioso.

Quase todos os frameworks de sites ou aplicações web oferecem suporte à inclusão de arquivos. A inclusão de arquivo é usada principalmente para empacotar código comum em arquivos separados que são posteriormente referenciados pelos módulos principais do aplicativo. Quando um site ou aplicação web faz referência a um arquivo de inclusão, o código neste arquivo pode ser executado implícita ou explicitamente chamando procedimentos específicos. Se a escolha do módulo a ser carregado for baseada em elementos da solicitação HTTP, o aplicativo da web pode ser vulnerável a RFI.

Um invasor pode usar RFI para:
* - Execução de código malicioso no servidor: qualquer código nos arquivos maliciosos incluídos será executado pelo servidor. Se o arquivo de inclusão não for executado usando algum wrapper, o código nos arquivos de inclusão será executado no contexto do usuário do servidor. Isso pode levar ao comprometimento total do sistema;
    
* - Execução de código malicioso nos clientes: o código malicioso do invasor pode manipular o conteúdo da resposta enviada ao cliente. O invasor pode inserir código malicioso na resposta que será executada pelo cliente (por exemplo, JavaScript para roubar os cookies da sessão do cliente).

O PHP é particularmente vulnerável a ataques RFI devido ao uso extensivo de "inclusões de arquivos" na programação PHP e devido às configurações de servidor padrão que aumentam a suscetibilidade a um ataque RFI.</desc>
	<solution>Fase: Arquitetura e Design.
Havendo um conjunto de objetos aceitáveis limitado e conhecido nesta fase (como nomes de arquivos ou URLs), crie o mapeamento de um conjunto de valores de entrada fixos (como IDs numéricos) para os nomes de arquivos ou URLs reais e rejeite quaisquer outras entradas.
Por exemplo, o ID 1 pode ser mapeado para "inbox.txt" e o ID 2 pode ser mapeado para "profile.txt". Recursos como o ESAPI AccessReferenceMap fornecem esse recurso.


Fases: Arquitetura e Design | Operação.
Execute seu código em uma "jail" ou ambiente sandbox similar que imponha limites estritos entre o processo e o sistema operacional. Isso pode restringir efetivamente quais arquivos podem ser acessados em um determinado diretório ou quais comandos podem ser executados por seu software.
Exemplos em nível de sistemas operacionais incluem Chroot Jail do Unix, AppArmor e SELinux. Em geral, código gerenciado pode fornecer alguma proteção. Por exemplo, java.io.FilePermission no Java SecurityManager permite especificar restrições nas operações de arquivo.
Essa pode não ser uma solução viável e apenas limita o impacto no sistema operacional; o restante de seu aplicativo ainda pode estar sujeito a comprometimento.
Tenha o cuidado de evitar a CWE-243 e outras vulnerabilidades relacionadas às jails.
Para PHP, o interpretador oferece restrições como open_basedir ou safe mode que podem tornar mais difícil para um invasor o escape do aplicativo. Considere também a Suhosin, uma extensão de PHP reforçada, que inclui várias opções que desabilitam alguns dos recursos mais perigosos do PHP.


Fase: Implementação.
Presuma que todas as entradas de dados são maliciosas. Use uma estratégia de validação de entrada "aceita como boa", ou seja, use uma lista de permissões de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Não confie exclusivamente na procura de entradas maliciosas ou malformadas (ou seja, não confie em uma lista de negação). No entanto, as listas de negação podem ser úteis para detectar ataques em potencial ou determinar quais entradas estão tão malformadas que devem ser rejeitadas imediatamente.
Ao executar a validação de entradas de dados, considere todas as propriedades potencialmente relevantes, incluindo comprimento, tipo de entrada, a gama completa de valores aceitáveis, entradas ausentes ou extras, sintaxe, consistência entre campos relacionados e conformidade com as regras de negócios. Como um exemplo de lógica de regra de negócios, "barco" pode ser sintaticamente válido porque contém apenas caracteres alfanuméricos, mas não é válido se você estiver esperando cores como "vermelho" ou "azul".
Para nomes de arquivos, use listas de permissões rigorosas que limitam o conjunto de caracteres a ser usado. Se possível, permita apenas um único caractere "." no nome do arquivo para evitar vulnerabilidades como a CWE-23 e exclua separadores de diretório como "/" para evitar a CWE-36. Use uma lista de permissões de extensões de arquivo permitidas, o que ajudará a evitar o CWE-434.


Fases: Arquitetura e Design | Operação.
Armazene arquivos de bibliotecas, inclusões e utilitários fora da raiz do documento da web, se possível. Caso contrário, armazene-os em um diretório separado e use os recursos de controle de acesso do servidor web para evitar que invasores os solicitem diretamente. Uma prática comum é definir uma constante fixa em cada programa de chamada e, em seguida, verificar a existência da constante no arquivo de biblioteca/inclusão; se a constante não existir, o arquivo foi solicitado diretamente e poderá sair imediatamente.
Isso reduz significativamente a chance de um invasor ser capaz de contornar quaisquer mecanismos de proteção que estão no programa de base, mas não nos arquivos de inclusão. Isso também reduzirá sua superfície de ataque.


Fases: Arquitetura e Design | Implementação.
Compreenda  todas as potenciais áreas onde entradas de dados não confiáveis podem ser inseridas em seu software: parâmetros ou argumentos, cookies, qualquer coisa lida a partir da rede, variáveis de ambiente, pesquisas de DNS reverso, resultados de consultas, cabeçalhos de solicitações, componentes de URLs, e-mails, arquivos, bancos de dados e quaisquer sistemas externos que forneçam dados para o aplicativo. Lembre-se de que essas entradas podem ser obtidas indiretamente por meio de chamadas de API.
Muitos problemas de inclusão de arquivo ocorrem porque o desenvolvedor presumiu que certas entradas não poderiam ser modificadas, especialmente para cookies e componentes de URL.</solution>
	<reference>http://projects.webappsec.org/Remote-File-Inclusion</reference>
	<reference>http://cwe.mitre.org/data/definitions/98.html</reference>
</vuln_item_wasc_5>

<vuln_items>wasc_6</vuln_items>
<vuln_item_wasc_6>
	<alert>Formato de String</alert>
	<desc>Ataques de Formato de String alteram o fluxo de um aplicativo usando recursos da biblioteca de formatação de string para acessar outro espaço de memória. As vulnerabilidades ocorrem quando dados fornecidos pelo usuário são usados diretamente como entrada de string de formatação para certas funções C/C ++ (por exemplo, fprintf, printf, sprintf, setproctitle, syslog, ...).

Se um invasor passar um formato de string que consiste em caracteres de conversão printf (por exemplo, "% f", "% p", "% n", etc.) como um valor de parâmetro para o aplicativo da web, eles podem:
* - Executar código arbitrário no servidor;
* - Ler os valores da pilha;
* - Causar falhas de segmentação/falhas de software.
Os ataques de formato de string estão relacionados a outros ataques na Threat Classification: estouros de buffer e estouros de inteiros. Todos os três são baseados em sua capacidade de manipular a memória ou sua interpretação de uma forma que contribui para o objetivo do invasor.</desc>
	<solution>Fase: Requisitos.
Escolha uma linguagem de programação que não esteja sujeita a essa falha.


Fase: Implementação.
Certifique-se de que todas as funções de formato de string sejam transmitidas a uma string estática que não pode ser controlada pelo usuário e que o número apropriado de argumentos também seja sempre enviado para essa função. Se possível, use funções que não suportam o operador %n no formato de strings.
Compilação: preste atenção aos avisos de compiladores e linkers, pois eles podem alertá-lo sobre o uso impróprio de formatos de strings.
</solution>
	<reference>http://projects.webappsec.org/Format-String</reference>
	<reference>http://cwe.mitre.org/data/definitions/134.html</reference>
</vuln_item_wasc_6>

<vuln_items>wasc_7</vuln_items>
<vuln_item_wasc_7>
	<alert>Estouro de Buffer</alert>
	<desc>Estouro de Buffer (Buffer Overflow) é uma falha que ocorre quando dados são gravados em volume maior do que um bloco de memória ou buffer estão alocados para conter. A exploração de um estouro de buffer permite que um invasor modifique partes do espaço de endereço do processo de destino. Essa capacidade pode ser usada para vários fins, incluindo o seguinte:
* - Controle da execução do processo;
* - Destruição (crash) do processo;
* - Modificação de variáveis internas.
O objetivo do atacante é quase sempre controlar a execução do processo alvo. Isso é feito identificando um ponteiro de função na memória que pode ser modificado direta ou indiretamente, usando o estouro. Quando esse ponteiro é usado pelo programa para direcionar a sua execução por meio de uma instrução de salto ou chamada, a localização da instrução fornecida pelo invasor será usada, permitindo assim que ele controle o processo.

Em muitos casos, o ponteiro de função é modificado para fazer referência a um local onde o invasor colocou instruções montadas específicas para a máquina. Essas instruções são comumente chamadas de código de shell, em referência ao fato de que os invasores geralmente desejam gerar um ambiente de linha de comando, ou shell, no contexto do processo de execução.

Estouros de buffer são mais frequentemente associados a software escrito nas linguagens de programação C e C ++ devido ao seu uso difundido e à capacidade de realizar manipulação direta de memória com construções comuns de programação. Deve-se enfatizar, entretanto, que estouros de buffer podem existir em qualquer ambiente de programação onde a manipulação direta de memória é permitida, seja por falhas no compilador, bibliotecas de tempo de execução ou recursos da própria linguagem.
</desc>
	<solution>
Fase: Requisitos.
Use uma linguagem que não permita que essa vulnerabilidade ocorra ou então forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.
Por exemplo, muitas linguagens que executam seu próprio gerenciamento de memória, como Java e Perl, não estão sujeitas a estouros de buffer. Outras linguagens, como Ada e C#, normalmente fornecem proteção contra estouro, mas a proteção pode ser desativada pelo desenvolvedor.
Fique atento, pois a interface de uma linguagem com o código nativo ainda pode estar sujeita a estouros, mesmo se a própria linguagem for teoricamente segura.


Fase: Arquitetura e Design.
Use uma biblioteca verificada ou framework que não permita que essa vulnerabilidade ocorra, ou forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.
Exemplos incluem a Safe C String Library (SafeStr) da Messier e Viega e a biblioteca Strsafe.h da Microsoft. Essas bibliotecas fornecem versões mais seguras de funções de manipulação de string sujeitas a estouro. Esta não é uma solução completa, uma vez que muitos estouros de buffer não estão relacionados a strings.


Fase: Construção e Compilação.
Execute ou compile seu software usando recursos ou extensões que fornecem automaticamente um mecanismo de proteção que atenue ou elimine estouros de buffer.
Por exemplo, certos compiladores e extensões fornecem mecanismos de detecção automática de estouro de buffer que são incorporados ao código compilado. Exemplos incluem o Microsoft Visual Studio/GS Flag, Fedora/Red Hat FORTIFY SOURCE GCC Flag, StackGuard e ProPolice.


Fase: Implementação.
Considere aderir às seguintes regras ao alocar e gerenciar a memória de um aplicativo:
* - Verifique mais de uma vez se seu buffer é tão grande quanto você especificou;
      
* - Ao usar funções que aceitam um número de bytes para copiar, como strncpy (), esteja ciente de que se o tamanho do buffer de destino for igual ao tamanho do buffer de origem, ele não pode terminar a string em NULL;
      
* - Verifique os limites do buffer ao chamar esta função em um loop e certifique-se de não correr o risco de gravar além do espaço alocado;
      
* - Se necessário, trunque todas as strings de entrada para um comprimento razoável antes de passá-las para as funções de cópia e concatenação.


Fase: Operação.
Use um recurso como o Address Space Layout Randomization (ASLR).


Fase: Operação.
Use uma CPU e um sistema operacional que ofereçam Data Execution Protection (NX) ou equivalente.


Fase: Implementação.
Substitua funções de cópia ilimitadas por funções análogas que suportam argumentos de comprimento, como strcpy com strncpy. Crie-as se não estiverem disponíveis.
</solution>
	<reference>http://projects.webappsec.org/Buffer-Overflow</reference>
	<reference>http://cwe.mitre.org/data/definitions/119.html</reference>
</vuln_item_wasc_7>

<vuln_items>wasc_8</vuln_items>
<vuln_item_wasc_8>
	<alert>Cross-Site Scripting (XSS)</alert>
	<desc>Cross-site Scripting (XSS) é uma técnica de ataque que envolve a replicação e execução de código fornecido pelo invasor na instância do navegador do usuário. Uma instância do navegador pode ser um cliente de navegador padrão ou um objeto de navegador incorporado em um produto de software, como o navegador no WinAmp, um leitor de RSS ou um cliente de e-mail. O código em si é geralmente escrito em HTML/JavaScript, mas também pode se estender para VBScript, ActiveX, Java, Flash ou qualquer outra tecnologia compatível com navegador.
Quando um invasor faz com que o navegador de um usuário execute seu código, o código será executado dentro do contexto de segurança (ou zona) do site de hospedagem. Com este nível de privilégio, o código tem a capacidade de ler, modificar e transmitir quaisquer dados confidenciais acessíveis pelo navegador. Um usuário afetado por script de cross-site pode ter sua conta sequestrada (roubo de cookie), seu navegador redirecionado para outro local ou possivelmente mostrando conteúdo fraudulento fornecido pelo suposto site que está visitando. Os ataques de script cross-site comprometem essencialmente a relação de confiança entre um usuário e o site. Aplicativos que utilizam instâncias de objeto de navegador que carregam conteúdo do sistema de arquivos podem executar código na zona da máquina local, permitindo o comprometimento do sistema.

Existem três tipos de ataques de Cross-site Scripting: não persistente, persistente e baseado em DOM.

Ataques não persistentes e ataques baseados em DOM exigem que o usuário visite um link especialmente criado com código malicioso ou visite uma página da web maliciosa contendo um formulário da web que, quando postado no site vulnerável, montará o ataque. O uso de um formulário mal-intencionado geralmente ocorre quando o recurso vulnerável aceita apenas solicitações HTTP POST. Nesse caso, o formulário pode ser enviado automaticamente sem o conhecimento da vítima (por exemplo, usando JavaScript). Ao clicar no link malicioso ou enviar o formulário malicioso, a carga XSS será ecoada de volta e será interpretada pelo navegador do usuário e executada. Outra técnica para enviar solicitações quase arbitrárias (GET e POST) é usar um cliente incorporado, como o Adobe Flash.

Ataques persistentes ocorrem quando o código malicioso é enviado a um site onde é armazenado por um período de tempo. Exemplos dos alvos favoritos de um invasor geralmente incluem postagens em quadros de mensagens, mensagens de webmail e software de bate-papo na web. Não é requerido do usuário desavisado, que interaja com qualquer site/link adicional (por exemplo, um site invasor ou um link malicioso enviado por e-mail), basta simplesmente visualizar a página da web que contém o código.</desc>
	<solution>
Fase: Arquitetura e Design.
Use uma biblioteca verificada ou framework que não permita que essa vulnerabilidade ocorra, ou forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.
Exemplos de bibliotecas e frameworks que facilitam a geração de saída codificada adequadamente incluem a biblioteca Anti-XSS da Microsoft, o módulo de codificação OWASP ESAPI e o Apache Wicket.


Fases: Implementação | Arquitetura e Design.
Compreenda o contexto no qual seus dados serão usados e a codificação que será esperada. Isso é especialmente importante ao transmitir dados entre componentes diferentes ou ao gerar saídas que podem conter várias codificações ao mesmo tempo, como páginas da web ou mensagens de e-mail com várias partes. Estude todos os protocolos de comunicação e representações de dados esperados para determinar as estratégias de codificação necessárias.
Para quaisquer dados que serão enviados para outra página da web, especialmente quaisquer dados recebidos de entradas externas, use a codificação apropriada em todos os caracteres não alfanuméricos.
Consulte a Página de Dicas de Prevenção de XSS para obter mais detalhes sobre os tipos de codificação e escape que são necessários.


Fase: Arquitetura e Design.
Para todas as verificações de segurança realizadas no lado do cliente, certifique-se de que essas verificações sejam duplicadas no lado do servidor, a fim de evitar a CWE-602. Invasores podem ignorar as verificações do lado do cliente, modificando os valores após a realização das verificações ou alterando o cliente para remover as verificações do lado do cliente completamente. Em seguida, esses valores modificados poderiam ser enviados ao servidor.

Se disponível, use mecanismos estruturados que impõem automaticamente a separação entre dados e código. Esses mecanismos podem ser capazes de fornecer citação, codificação e validação relevantes automaticamente, em vez de depender do desenvolvedor para fornecer esse recurso em cada ponto onde a saída é gerada.


Fase: Implementação.
Para cada página web gerada, use e especifique uma codificação de caracteres, como ISO-8859-1 ou UTF-8. Quando uma codificação não é especificada, o navegador pode escolher uma codificação diferente, tentando adivinhar por eliminação qual codificação está realmente sendo usada pela página da web. Isso pode fazer com que o navegador da web trate certas sequências como especiais, abrindo o cliente para ataques XSS sutis. Consulte a CWE-116 para obter mais informações sobre mitigações relacionadas à codificação/escape.

Para ajudar a mitigar os ataques XSS contra cookie de sessão do usuário, defina o cookie de sessão como HttpOnly. Em navegadores que suportam o recurso HttpOnly (como versões mais recentes do Internet Explorer e Firefox), esse atributo pode impedir que o cookie de sessão do usuário seja acessível a scripts mal-intencionados do lado do cliente que usam document.cookie. Esta não é uma solução completa, já que HttpOnly não é compatível com todos os navegadores. Mais importante ainda, XMLHTTPRequest e outras poderosas tecnologias de navegadores fornecem acesso de leitura a cabeçalhos HTTP, incluindo o cabeçalho Set-Cookie no qual o sinalizador HttpOnly é definido.

Presuma que toda a entrada de dados é maliciosa. Use uma estratégia de validação de entrada "aceita como boa", ou seja, use uma lista de permissões de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Não confie exclusivamente na procura de entradas maliciosas ou malformadas (ou seja, não confie em uma lista de negação). No entanto, as listas de negação podem ser úteis para detectar ataques em potencial ou determinar quais entradas estão tão malformadas que devem ser rejeitadas imediatamente.

Ao executar a validação de entradas de dados, considere todas as propriedades potencialmente relevantes, incluindo comprimento, tipo de entrada, a gama completa de valores aceitáveis, entradas ausentes ou extras, sintaxe, consistência entre campos relacionados e conformidade com as regras de negócios. Como um exemplo de lógica de regra de negócios, "barco" pode ser sintaticamente válido porque contém apenas caracteres alfanuméricos, mas não é válido se você estiver esperando cores como "vermelho" ou "azul".

Certifique-se de realizar a validação de entrada em interfaces bem definidas dentro do aplicativo. Isso ajudará a proteger o aplicativo, mesmo se um componente for reutilizado ou movido para outro lugar.
	</solution>
	<reference>http://projects.webappsec.org/Cross-Site-Scripting</reference>
	<reference>http://cwe.mitre.org/data/definitions/79.html</reference>
</vuln_item_wasc_8>

<vuln_items>wasc_9</vuln_items>
<vuln_item_wasc_9>
	<alert>Cross-Site Request Forgery (CSRF)</alert>
	<desc>Uma falsificação de solicitação entre sites (Cross-Site Request Forgery ou simplesmente CSRF)  é um ataque que envolve forçar a vítima a enviar uma solicitação HTTP a um destino alvo sem seu conhecimento ou intenção, a fim de realizar uma ação como a vítima. A causa implícita é a funcionalidade do aplicativo usando ações previsíveis em URLs/formulários, de maneira repetível. A natureza do ataque é que o CSRF explora a confiança que um site tem em um usuário. Em contrapartida, um ataque do tipo Cross-Site Scripting (XSS) explora a confiança que um usuário tem em um site. Como o XSS, os ataques CSRF não são necessariamente entre sites, mas também podem ser. A falsificação de solicitação entre sites também é conhecida por "CSRF", "XSRF", "one-click attack", "session riding", "confused deputy", e "sea surf".


Os ataques CSRF são efetivos em várias situações, incluindo:
* - A vítima tem uma sessão ativa no site de destino;
    
* - A vítima está autenticada por meio de autenticação HTTP no site de destino;
    
* - A vítima está na mesma rede local do site de destino.


O CSRF era usado principalmente para executar ações contra um site-alvo usando os privilégios da vítima, mas técnicas recentes foram descobertas para vazamento de informações obtendo acesso às respostas. O risco de vazamento/divulgação não autorizada de informações aumenta drasticamente quando o site de destino é vulnerável a XSS, porque o XSS pode ser usado como uma plataforma para CSRF, permitindo que o ataque opere dentro dos limites da política de mesma origem.</desc>
	<solution>
Fase: Arquitetura e Design.
Use uma biblioteca verificada ou framework que não permita que essa vulnerabilidade ocorra, ou forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.
Por exemplo, use pacotes anti-CSRF, como o OWASP CSRFGuard.


Fase: Implementação.
Certifique-se de que seu aplicativo esteja livre de problemas de cross-site scripting (XSS), porque a maioria das defesas CSRF pode ser contornada usando script controlado por invasor.


Fase: Arquitetura e Design.
Gere um número arbitrário de uso único e exclusivo (ou Nonce = "N" de "number" - número em inglês - e "once" de "uma vez" também em inglês) para cada formulário, coloque o nonce no formulário e verifique-o ao receber o formulário. Certifique-se de que o nonce não seja previsível (CWE-330).
Observe que isso pode ser contornado usando XSS.

Identifique operações especialmente perigosas. Quando o usuário realizar uma operação perigosa, envie uma solicitação de confirmação separada para garantir que o usuário pretendia realizar aquela operação.
Observe que isso pode ser contornado usando XSS.

Utilize o controle ESAPI Session Management.
Este controle inclui um componente para CSRF.

Não use o método GET para qualquer solicitação que acione uma mudança de estado.


Fase: Implementação.
Verifique o cabeçalho HTTP Referer para ver se a solicitação foi originada de uma página esperada. Isso pode interromper funcionalidades legítimas, porque os usuários ou proxies podem ter desativado o envio do Referer por motivos de privacidade.</solution>
	<reference>http://projects.webappsec.org/Cross-Site-Request-Forgery</reference>
	<reference>http://cwe.mitre.org/data/definitions/352.html</reference>
</vuln_item_wasc_9>

<vuln_items>wasc_10</vuln_items>
<vuln_item_wasc_10>
	<alert>Denial of Service (DoS Attack ou DDoS)</alert>
	<desc>Denial of Service (DoS) é uma técnica de ataque com a intenção de impedir que um site da Web atenda à atividade normal do usuário. Ataques DoS, que normalmente são facilmente aplicados à camada de rede, também são possíveis na camada de aplicativo. Esses ataques maliciosos podem ter sucesso privando um sistema de recursos críticos, explorando vulnerabilidades ou abusando de funcionalidades.

Muitas vezes, os ataques DoS tentarão consumir todos os recursos de sistema disponíveis em um site, como: CPU, memória, espaço em disco, etc. Quando qualquer um desses recursos críticos atingir a utilização total, o site normalmente ficará inacessível.

Como os ambientes de aplicativos web atuais quase sempre incluem um servidor da Web, um servidor de banco de dados e um servidor de autenticação, o DoS na camada de aplicativo pode ter como alvo cada um desses componentes independentes. Ao contrário do DoS na camada de rede, onde é necessário um grande número de tentativas de conexão, o DoS na camada de aplicativo é uma tarefa muito mais simples de executar.</desc>
	<solution>Fase: Arquitetura e Design.
Projete mecanismos de limitação na arquitetura do sistema. A melhor proteção é limitar a quantidade de recursos que um usuário não autorizado pode fazer com que sejam gastos. Um modelo de autenticação forte e controle de acesso ajudará a evitar que tais ataques ocorram em primeiro lugar. O aplicativo de login deve ser protegido contra ataques DoS tanto quanto possível. Limitar o acesso ao banco de dados por exemplo armazenando conjuntos de resultados em cache, pode ajudar a minimizar os recursos gastos. Para limitar ainda mais o potencial de um ataque DoS, considere rastrear a taxa de solicitações recebidas de usuários e bloquear solicitações que excedam um limite de taxa definido.


A mitigação de ataques de exaustão de recursos requer que o sistema alvo:
* - Reconheça o ataque e negue a esse usuário acesso adicional por um determinado período de tempo, ou;
* - Regule uniformemente todas as solicitações para dificultar o consumo de recursos mais rapidamente do que eles poderiam ser novamente liberados. 


A primeira dessas soluções é um problema em si, pois pode permitir que invasores impeçam o uso do sistema por um determinado usuário válido. Se o invasor se passar por um usuário válido, ele poderá impedir que o usuário acesse o servidor em questão.


A segunda solução é simplesmente difícil de implementar com eficácia - e mesmo quando feita de maneira adequada, não oferece uma solução completa. Isso simplesmente faz com que o ataque exija mais recursos por parte do invasor.

Certifique-se de que os protocolos têm limites específicos de escala colocados neles.


Fase: Implementação.
Certifique-se de que todas as falhas na alocação de recursos não colocam o sistema em uma posição insegura.</solution>
	<reference>http://projects.webappsec.org/Denial-of-Service</reference>
	<reference>http://cwe.mitre.org/data/definitions/400.html</reference>
</vuln_item_wasc_10>

<vuln_items>wasc_11a</vuln_items>
<vuln_item_wasc_11a>
	<alert>Brute Forcing em Credenciais de Login</alert>
	<desc>Um ataque de força bruta (Brute Force Attack) é um método utilizado para descobrir um valor desconhecido usando um processo automatizado para tentar um grande número de possíveis valores. O ataque aproveita o fato de que a incerteza a respeito da origem/fonte dos valores, é menor que o percebido. Por exemplo, embora uma senha alfanumérica de 8 caracteres possa ter 2,8 trilhões de valores possíveis, muitas pessoas selecionarão suas senhas em um subconjunto muito menor que consiste em palavras e termos comuns.

O tipo mais comum de ataque de força bruta em aplicativos da web é um ataque contra credenciais de login. Como os usuários precisam se lembrar de senhas, eles geralmente selecionam para tal, palavras ou frases fáceis de memorizar, fazendo com que o uso de um  dicionário de possíveis frases, termos e combinações seja muito útil em um ataque de força bruta. Esse tipo de ataque de tentativa de login em um sistema usando uma grande lista de palavras e frases como senhas em potencial é freqüentemente chamado de "ataque de lista de palavras" ou "ataque de dicionário". As tentativas de senha também podem incluir variações de palavras comuns em senhas, como aquelas geradas pela substituição de "o" por "0" e "i" por "1", bem como informações pessoais, incluindo nomes de familiares, datas de nascimento e números de telefone.
	</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>Uma solução será disponibilizada em breve.</reference>
</vuln_item_wasc_11a>

<vuln_items>wasc_11b</vuln_items>
<vuln_item_wasc_11b>
	<alert>Brute Forcing em Identificadores de Seção</alert>
	<desc>Um ataque de força bruta (Brute Force Attack) é um método utilizado para descobrir um valor desconhecido usando um processo automatizado para tentar um grande número de possíveis valores. O ataque aproveita o fato de que a incerteza a respeito da origem/fonte dos valores, é menor que o percebido. Por exemplo, embora uma senha alfanumérica de 8 caracteres possa ter 2,8 trilhões de valores possíveis, muitas pessoas selecionarão suas senhas em um subconjunto muito menor que consiste em palavras e termos comuns.

Como o HTTP é um protocolo sem estado, para manter o estado os aplicativos da web precisam garantir que um identificador de sessão seja enviado pelo navegador com cada solicitação. O identificador de sessão é mais comumente armazenado em um cookie HTTP ou URL. Usando um ataque de força bruta, um invasor pode adivinhar o identificador de sessão de outro usuário. Isso pode fazer com que o invasor se faça passar pelo usuário, obtendo informações pessoais e realizando ações em nome do usuário.
	</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>Uma solução será disponibilizada em breve.</reference>
</vuln_item_wasc_11b>

<vuln_items>wasc_11c</vuln_items>
<vuln_item_wasc_11c>
	<alert>Brute Forcing em Diretórios e Arquivos</alert>
	<desc>Um ataque de força bruta (Brute Force Attack) é um método utilizado para descobrir um valor desconhecido usando um processo automatizado para tentar um grande número de possíveis valores. O ataque aproveita o fato de que a incerteza a respeito da origem/fonte dos valores, é menor que o percebido. Por exemplo, embora uma senha alfanumérica de 8 caracteres possa ter 2,8 trilhões de valores possíveis, muitas pessoas selecionarão suas senhas em um subconjunto muito menor que consiste em palavras e termos comuns.

Quando os arquivos estão alocados em diretórios disponibilizados pelo servidor da web mas não estão vinculados a nenhum lugar, o acesso a esses arquivos requer o conhecimento de seus nomes. Em alguns casos, esses arquivos foram deixados por engano: por exemplo, um arquivo de backup criado automaticamente ao editar um arquivo ou sobras de uma versão mais antiga da aplicação web. Em outros casos, os arquivos são intencionalmente desvinculados como um mecanismo de "segurança por obscuridade", permitindo que apenas pessoas que conheçam os nomes dos arquivos tenham acesso a eles.

Um ataque de força bruta tenta localizar o arquivo desvinculado tentando acessar um grande número de arquivos. A lista de nomes de arquivos tentados pode ser obtida de uma lista de arquivos potenciais conhecidos ou com base em variantes dos arquivos visíveis no site. Mais informações sobre ataques de força bruta em diretórios e arquivos podem ser encontradas na vulnerabilidade associada, localização de recurso previsível.
	</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>Uma solução será disponibilizada em breve.</reference>
</vuln_item_wasc_11c>

<vuln_items>wasc_11d</vuln_items>
<vuln_item_wasc_11d>
	<alert>Brute Forcing em Informações de Cartão de Crédito</alert>
	<desc>Um ataque de força bruta (Brute Force Attack) é um método utilizado para descobrir um valor desconhecido usando um processo automatizado para tentar um grande número de possíveis valores. O ataque aproveita o fato de que a incerteza a respeito da origem/fonte dos valores, é menor que o percebido. Por exemplo, embora uma senha alfanumérica de 8 caracteres possa ter 2,8 trilhões de valores possíveis, muitas pessoas selecionarão suas senhas em um subconjunto muito menor que consiste em palavras e termos comuns.

Geralmente, as compras online com cartões de crédito roubados exigem informações além do número do cartão de crédito, na maioria das vezes o CVV/SCS e/ou a data de validade. Um fraudador pode obter um número de cartão de crédito roubado sem as informações adicionais. Por exemplo, o CVV/CSC não é impresso no cartão ou armazenado na tarja magnética, portanto não pode ser coletado por dispositivos mecânicos ou magnéticos de leitura de cartão de crédito.

Para completar as informações ausentes, o hacker pode adivinhar as informações ausentes usando uma técnica de força bruta, tentando todos os valores possíveis.
    
* - Adivinhar CVV/CSC requer apenas 1000 ou 10000 tentativas, pois o número tem apenas 3 ou 4 dígitos, dependendo do tipo de cartão;
    
* - Adivinhar uma data de expiração requer apenas algumas dezenas de tentativas.
	</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>Uma solução será disponibilizada em breve.</reference>
</vuln_item_wasc_11d>

<vuln_items>wasc_12</vuln_items>
<vuln_item_wasc_12>
	<alert>Falsificação de Conteúdo</alert>
	<desc>A falsificação de conteúdo (Content Spoofing) é uma técnica de ataque que permite a um invasor injetar uma carga maliciosa que mais tarde é deturpada como conteúdo legítimo de um aplicativo da web.
 

Falsificação de Conteúdo Apenas Texto:
Uma abordagem comum para criar páginas dinamicamente envolve passar o corpo ou partes dele para a página por meio de um valor de string de consulta. Essa abordagem é comum em páginas de erro ou sites que fornecem entradas de histórias ou notícias. O conteúdo especificado neste parâmetro é refletido posteriormente na página para fornecer o conteúdo da página.
 

Falsificação de Conteúdo por Marcação Refletida:
Algumas páginas da web são veiculadas usando fontes de conteúdo HTML construídas dinamicamente. Por exemplo, a localização de origem de um quadro <frame src="http://foo.example/file.html"/>) pode ser especificado por um valor de parâmetro de URL. (http://foo.example/page?frame_src=http://foo.example/file.html). Um invasor pode substituir o valor do parâmetro "frame_src" por "frame_src = http://attacker.example/spoof.html". Ao contrário dos redirecionadores, quando a página da web resultante é exibida, a barra de localização do navegador permanece visivelmente sob o domínio esperado do usuário (foo.example), mas os dados externos (attacker.example) são encobertos por conteúdo legítimo.

Links especialmente criados podem ser enviados a um usuário por e-mail, mensagens instantâneas, deixados em publicações de boletins ou forçados a usuários por um ataque de Cross-site Scripting (XSS). Se um invasor faz com que um usuário visite uma página da web designada por sua URL maliciosa, o usuário acreditará que está visualizando conteúdo autêntico, quando não está. Os usuários confiarão implicitamente no conteúdo falsificado, pois a barra de localização do navegador exibe http://foo.example, quando na verdade o quadro HTML subjacente está fazendo referência a http://attacker.example.

Este ataque explora a relação de confiança estabelecida entre o usuário e o site. A técnica tem sido usada para criar páginas da web falsas, incluindo formulários de login, desfiguração de sites, comunicados de imprensa falsos, etc.
	</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Content-Spoofing</reference>
	<reference>Uma solução será disponibilizada em breve.</reference>
</vuln_item_wasc_12>

<vuln_items>wasc_13</vuln_items>
<vuln_item_wasc_13>
	<alert>Vazamento de Informações</alert>
	<desc>O vazamento de informações é um ponto fraco de aplicações, em que o mesmo revela dados confidenciais, como detalhes técnicos da aplicação de web, ambiente ou dados específicos do usuário. Dados confidenciais podem ser usados por um invasor para explorar a aplicação web de destino, sua rede de hospedagem ou seus usuários. Portanto, o vazamento de dados confidenciais deve ser limitado ou evitado sempre que possível. O vazamento de informações, em sua forma mais comum, é o resultado de uma ou mais das seguintes condições: Falha ao remover comentários de HTML/Script contendo informações confidenciais, configurações de aplicação ou servidor impróprios ou diferenças nas respostas da página para dados válidos versus dados inválidos.

A falha ao limpar os comentários de HTML/Script antes de enviar para o ambiente de produção pode resultar no vazamento de informações confidenciais e contextuais, como estrutura de diretório do servidor, estrutura de consulta SQL e informações de rede interna. Freqüentemente, um desenvolvedor deixará comentários dentro do código HTML e/ou script para ajudar a facilitar o processo de depuração ou integração durante a fase de pré-produção. Embora não haja nenhum dano em permitir que os desenvolvedores incluam comentários embutidos no conteúdo que desenvolvem, esses comentários devem ser todos removidos antes do lançamento público do conteúdo.

Números de versão de software e mensagens de erro detalhadas (como números de versão ASP.NET) são exemplos de configurações de servidor inadequadas. Essas informações são úteis para um invasor, fornecendo uma visão detalhada da estrutura, linguagens ou funções pré-construídas utilizadas por uma aplicação web. A maioria das configurações de servidor padrão fornece números de versão de software e mensagens de erro detalhadas para fins de depuração e solução de problemas. Alterações de configuração podem ser feitas para desabilitar esses recursos, impedindo a exibição dessas informações.

Páginas que fornecem respostas diferentes com base na validade dos dados também podem levar ao vazamento de informações; especificamente quando dados considerados confidenciais estão sendo revelados como resultado do design do aplicativo da web. Exemplos de dados confidenciais incluem (mas não se limitam a): números de contas, identificadores de usuários (número da carteira de habilitação, número do passaporte, números de CPF etc.) e informações específicas do usuário (senhas, sessões, endereços). O Vazamento de Informações, neste contexto, trata da exposição dos principais dados do usuário considerados confidenciais ou secretos, que não devem ser expostos à vista, mesmo para o usuário. Números de cartão de crédito e outras informações altamente regulamentadas são exemplos importantes de dados do usuário que precisam ser protegidos contra exposição ou vazamento, mesmo com criptografia adequada e controles de acesso já implementados.</desc>
	<solution>Compartimentalize seu sistema para ter áreas "seguras" onde os limites de confiança possam ser definidos de forma inequívoca. Não permita que dados confidenciais saiam do limite de confiança e sempre tenha cuidado ao fazer a interface com um compartimento fora da área segura.</solution>
	<reference>http://projects.webappsec.org/Information-Leakage</reference>
	<reference>http://cwe.mitre.org/data/definitions/200.html</reference>
</vuln_item_wasc_13>

<vuln_items>wasc_14</vuln_items>
<vuln_item_wasc_14>
	<alert>Configuração Incorreta de Servidor</alert>
	<desc>Ataques de configuração incorreta de servidor exploram os pontos fracos de configuração encontrados em servidores web e servidores de aplicativos. Muitos servidores vêm com arquivos padrão e de amostra desnecessários, incluindo aplicativos, arquivos de configuração, scripts e páginas da web. Eles também podem ter serviços desnecessários habilitados, como gerenciamento de conteúdo e funcionalidade de administração remota. Funções de depuração podem ser habilitadas ou funções administrativas podem ser acessíveis a usuários anônimos. Esses recursos podem fornecer meios para um hacker contornar os métodos de autenticação e obter acesso a informações confidenciais, talvez com privilégios elevados.

Os servidores podem incluir contas e senhas padrão bem conhecidas. A falha em bloquear ou proteger totalmente o servidor pode deixar permissões de arquivo e diretório configuradas incorretamente. Certificados SSL e conformações de criptografia mal configurados, o uso de certificados padrão e a implementação de autenticação inadequada com sistemas externos podem comprometer a confidencialidade das informações.

Mensagens de erro detalhadas e informativas podem resultar em vazamento de dados, e as informações reveladas podem ser usadas para formular o próximo nível de ataque. Configurações incorretas no software do servidor podem permitir a indexação de diretório e ataques de travessia/passagem de caminho.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Server-Misconfiguration</reference>
	<reference/>
</vuln_item_wasc_14>

<vuln_items>wasc_15</vuln_items>
<vuln_item_wasc_15>
	<alert>Configuração Incorreta de Aplicação</alert>
	<desc>Ataques de configuração incorreta de aplicação exploram os pontos fracos de configuração encontrados em aplicações web. Muitas aplicações vêm com recursos desnecessários e inseguros, como recursos de depuração e controle de qualidade, habilitados por padrão. Esses recursos podem fornecer meios para um hacker contornar os métodos de autenticação e obter acesso a informações confidenciais, talvez com privilégios elevados.

Da mesma forma, as instalações padrão podem incluir nomes de usuário e senhas bem conhecidos, contas backdoor codificadas, mecanismos de acesso especiais e permissões incorretas definidas para arquivos acessíveis por meio de servidores da web. Samples padrão podem estar acessíveis em ambientes de produção. Arquivos de configuração baseados em aplicativos que não são bloqueados adequadamente podem revelar strings de conexão de texto não criptografado para o banco de dados, e as configurações padrão nos arquivos de configuração podem não ter sido definidas com a segurança em mente. Todas essas configurações incorretas podem levar ao acesso não autorizado a informações confidenciais.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Application-Misconfiguration</reference>
	<reference/>
</vuln_item_wasc_15>

<vuln_items>wasc_16</vuln_items>
<vuln_item_wasc_16>
	<alert>Indexação de Diretório</alert>
	<desc>Listagem/indexação automática de diretório é uma função de servidor web que lista todos os arquivos dentro de um diretório solicitado se o arquivo base normal (index.html/home.html/default.htm/default.asp/default.aspx/index.php) não está presente. Quando um usuário solicita a página principal de um site, ele normalmente digita uma URL como: http://www.example.com/directory1/ - usando o nome do domínio e excluindo um arquivo específico. O servidor web processa essa solicitação e pesquisa o diretório raiz do documento em busca do nome de arquivo padrão e envia esta página ao cliente. Se esta página não estiver presente, o servidor web emitirá dinamicamente uma lista de diretórios e enviará a saída ao cliente. Essencialmente, isso é equivalente a emitir um comando "ls" (Unix) ou "dir" (Windows) dentro deste diretório e mostrar os resultados em formato HTML. De uma perspectiva de ataque e contramedida, é importante perceber que listagens de diretório não intencionais podem ser possíveis devido a vulnerabilidades de software (discutidas na seção de exemplo abaixo) combinadas com uma solicitação da web específica.</desc>
	<solution>As recomendações incluem restringir o acesso a diretórios ou arquivos importantes, adotando a necessidade de saber um requisito tanto para o documento quanto para a raiz do servidor, e desligar recursos como listas automáticas de diretórios que podem expor arquivos privados e fornecer informações que podem ser utilizadas por um invasor ao formular ou conduzir um ataque.</solution>
	<reference>http://projects.webappsec.org/Directory-Indexing</reference>
	<reference>http://cwe.mitre.org/data/definitions/548.html</reference>
</vuln_item_wasc_16>

<vuln_items>wasc_17</vuln_items>
<vuln_item_wasc_17>
	<alert>Permissões Inadequadas no Sistema de Arquivos</alert>
	<desc>Permissões inadequadas no filesystem são uma ameaça à confidencialidade, integridade e disponibilidade de uma aplicação web. O problema surge quando as permissões incorretas do sistema de arquivos são definidas em arquivos, pastas e links simbólicos. Quando as permissões inadequadas são definidas, um invasor pode acessar arquivos ou diretórios restritos e modificar ou excluir seu conteúdo. Por exemplo, se uma conta de usuário anônimo tiver permissão de gravação em um arquivo, um invasor poderá modificar o conteúdo do arquivo influenciando a aplicação web de maneiras indesejáveis. Um invasor também pode explorar links simbólicos impróprios para aumentar seus privilégios e/ou acessar arquivos não autorizados; por exemplo, um link simbólico que aponta para um diretório fora da raiz da web.</desc>
	<solution>Gerencie com muito cuidado a configuração, gerenciamento e manuseio de permissões. Gerencie de forma explícita as zonas permitidas no software.</solution>
	<reference>http://projects.webappsec.org/Improper-Filesystem-Permissions</reference>
	<reference>http://cwe.mitre.org/data/definitions/280.html</reference>
</vuln_item_wasc_17>

<vuln_items>wasc_18</vuln_items>
<vuln_item_wasc_18>
	<alert>Previsão de Credencial e Sessão</alert>
	<desc>Previsão de Credencial/Sessão é um método de sequestro de seção ou a simulação de ser um usuário de site. Deduzindo ou adivinhando o valor exclusivo que identifica uma determinada sessão ou usuário, o ataque é completado. Também conhecido como sequestro de sessão, as consequências podem permitir que os invasores façam solicitações de sites com os privilégios do usuário comprometido.

Muitos sites são projetados para autenticar e rastrear um usuário quando a comunicação é estabelecida pela primeira vez. Para fazer isso, os usuários devem provar sua identidade para o site, normalmente fornecendo uma combinação de nome de usuário/senha (credenciais). Em vez de passar essas credenciais confidenciais para frente e para trás com cada transação, os sites irão gerar um "ID de sessão" exclusivo para identificar a sessão do usuário como autenticada. A comunicação subsequente entre o usuário e o site é marcada com o ID da sessão como "prova" da sessão autenticada. Se um invasor for capaz de prever ou adivinhar o ID da sessão de outro usuário, a atividade fraudulenta é possível.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Credential-and-Session-Prediction</reference>
	<reference/>
</vuln_item_wasc_18>

<vuln_items>wasc_19</vuln_items>
<vuln_item_wasc_19>
	<alert>Injeção SQL</alert>
	<desc>Injeção SQL (SQL Injection) é uma técnica de ataque usada para explorar aplicações que constroem instruções SQL a partir de entradas fornecidas pelo usuário. Quando bem-sucedido, o invasor consegue alterar a lógica das instruções SQL executadas no banco de dados.

Structured Query Language (SQL) é uma linguagem de programação especializada para enviar consultas a bancos de dados. A linguagem de programação SQL é um padrão tanto ANSI quanto ISO, embora muitos produtos de banco de dados que suportam SQL o façam com extensões proprietárias para a linguagem padrão. Aplicações geralmente usam dados fornecidos pelo usuário para criar instruções SQL. Se uma aplicação não consegue construir instruções SQL de maneira adequada, é possível que um invasor altere a estrutura da instrução e execute comandos não planejados e potencialmente hostis. Quando esses comandos são executados, eles o fazem no contexto do usuário especificado pelo aplicativo que executa a instrução. Esse recurso permite que os invasores obtenham o controle de todos os recursos do banco de dados acessíveis por esse usuário, incluindo até a capacidade de executar comandos no sistema de hospedagem.</desc>
	<solution>
Fase: Arquitetura e Design.
Use uma biblioteca verificada ou framework que não permita que essa vulnerabilidade ocorra, ou forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.
Por exemplo, considere o uso de camadas de persistência como Hibernate ou Enterprise Java Beans, que podem fornecer proteção significativa contra injeção de SQL se usadas corretamente.

Se disponível, use mecanismos estruturados que impõem automaticamente a separação entre dados e código. Esses mecanismos podem ser capazes de fornecer citação, codificação e validação relevantes automaticamente, em vez de depender do desenvolvedor para fornecer esse recurso em cada ponto onde a saída é gerada.

Processe consultas SQL usando instruções preparadas, consultas parametrizadas ou procedimentos armazenados (stored-procedures). Esses recursos devem aceitar parâmetros ou variáveis e suportar tipagem forte. Não construa e execute dinamicamente strings de consulta dentro desses recursos usando "exec" ou funcionalidade semelhante, pois você pode reintroduzir a possibilidade de injeção de SQL.

Execute seu código usando os privilégios mais baixos possíveis para realizar as tarefas necessárias. Se possível, crie contas isoladas com privilégios limitados que serão usados apenas para uma única tarefa. Dessa forma, um ataque bem-sucedido não dará ao invasor acesso imediato ao restante do software ou ao seu ambiente. Por exemplo, os aplicativos de banco de dados raramente precisam ser executados como administrador de banco de dados, especialmente nas operações do dia a dia.

Especificamente, siga o princípio do menor privilégio ao criar contas de usuário em um banco de dados SQL. Os usuários do banco de dados devem ter apenas os privilégios mínimos necessários para usar sua conta. Se os requisitos do sistema indicarem que um usuário pode ler e modificar seus próprios dados, limite seus privilégios para que não possam ler/gravar dados de terceiros. Use as permissões mais estritas possíveis em todos os objetos de banco de dados, como "somente execução" para stored-procedures.


Fase: Implementação.
Se você precisar usar strings de consulta ou comandos gerados dinamicamente apesar do risco, cite corretamente os argumentos e retire quaisquer caracteres especiais dentro desses argumentos. A abordagem mais conservadora é escapar ou filtrar todos os caracteres que não passam em uma lista de permissões extremamente restrita (como tudo que não é alfanumérico ou espaço em branco). Se alguns caracteres especiais ainda forem necessários, como espaço em branco, coloque cada argumento entre aspas após a etapa de escape/filtragem. Tenha cuidado com a injeção de argumentos (CWE-88).

Em vez de construir sua própria implementação, tais recursos podem estar disponíveis no banco de dados ou linguagem de programação. Por exemplo, o pacote Oracle DBMS ASSERT pode verificar ou garantir que os parâmetros tenham certas propriedades que os tornam menos vulneráveis à injeção de SQL. Para o MySQL, a função da API mysql real escape string () está disponível tanto em C quanto em PHP.

Presuma que toda a entrada de dados é maliciosa. Use uma estratégia de validação de entrada "aceita como boa", ou seja, use uma lista de permissões de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Não confie exclusivamente na procura de entradas maliciosas ou malformadas (ou seja, não confie em uma lista de negação). No entanto, as listas de negação podem ser úteis para detectar ataques em potencial ou determinar quais entradas estão tão malformadas que devem ser rejeitadas imediatamente.

Ao executar a validação de entradas de dados, considere todas as propriedades potencialmente relevantes, incluindo comprimento, tipo de entrada, a gama completa de valores aceitáveis, entradas ausentes ou extras, sintaxe, consistência entre campos relacionados e conformidade com as regras de negócios. Como um exemplo de lógica de regra de negócios, "barco" pode ser sintaticamente válido porque contém apenas caracteres alfanuméricos, mas não é válido se você estiver esperando cores como "vermelho" ou "azul".

Ao construir cadeias de caracteres de consulta SQL, use listas de permissão rigorosas que limitam o conjunto de caracteres com base no valor esperado do parâmetro na solicitação. Isso limitará indiretamente o escopo de um ataque, mas essa técnica é menos importante do que a codificação de saída adequada e o escape.

Observe que a codificação, escape e citação de saída adequados são a solução mais eficaz para evitar injeção de SQL, embora a validação de entrada possa fornecer alguma defesa em profundidade. Isso ocorre porque ele limita efetivamente o que aparecerá na saída. A validação de entrada nem sempre impedirá a injeção de SQL, especialmente se você precisar oferecer suporte a campos de texto de formato livre que podem conter caracteres arbitrários. Por exemplo, o nome "O'Reilly" provavelmente passaria na etapa de validação, uma vez que é um sobrenome comum no idioma inglês. No entanto, ele não pode ser inserido diretamente no banco de dados porque contém o caractere de apóstrofo " ' ", que precisaria ser ignorado ou manipulado de outra forma. Nesse caso, retirar o apóstrofo pode reduzir o risco de injeção SQL, mas produziria um comportamento incorreto porque o nome errado seria registrado.

Quando viável, pode ser mais seguro proibir totalmente os metacaracteres, em vez de evitá-los. Isso fornecerá alguma defesa em profundidade. Depois que os dados forem inseridos no banco de dados, processos posteriores podem negligenciar o escape de metacaracteres antes do uso, e você pode não ter controle sobre esses processos.</solution>
	<reference>http://projects.webappsec.org/SQL-Injection</reference>
	<reference/>
</vuln_item_wasc_19>

<vuln_items>wasc_20</vuln_items>
<vuln_item_wasc_20>
	<alert>Tratamento Inadequado de Entrada de Dados</alert>
	<desc>O tratamento inadequado de entrada de dados é uma das fraquezas mais comuns identificadas nos aplicativos hoje. Uma entrada mal tratada é uma das principais causas por trás de vulnerabilidades críticas que existem em sistemas e aplicações.
	
Geralmente, o termo tratamento de entrada é usado para descrever funções como validação, sanitização, filtragem, codificação e/ou decodificação de dados de entrada. As aplicações recebem entradas de várias fontes, incluindo usuários humanos, agentes de software (navegadores) e dispositivos de rede/periféricos, só para citar alguns. No caso de aplicações web, a entrada pode ser transferida em vários formatos (pares nome-valor, JSON, SOAP, etc...) e obtida por meio de strings de consulta de URL, dados POST, cabeçalhos HTTP, Cookies, etc... Entradas de aplicações não-web podem ser obtidas por meio de variáveis de aplicativo, variáveis de ambiente, registro, arquivos de configuração, etc... Independentemente do formato dos dados ou da fonte/localização da entrada de dados, todas elas devem ser consideradas não confiáveis e potencialmente maliciosas. Aplicações que processam entradas de dados não confiáveis podem se tornar vulneráveis a ataques como Estouro de Buffer, Injeção SQL, Comandos de Sistema Operacional, Negação de Serviço, apenas para citar alguns.

Um dos principais aspectos do tratamento de entrada de dados é validar se ela satisfaz um determinado critério. Para uma validação adequada, é importante identificar a forma e o tipo de dados que são aceitáveis e esperados pela aplicação. A definição de um formato esperado e do uso de cada instância de entrada não confiável é necessária para definir as restrições com precisão. 

A validação pode incluir verificações de segurança de tipo e sintaxe correta. A entrada da string pode ser verificada quanto ao comprimento (número mínimo e máximo de caracteres) e validação do conjunto de caracteres, enquanto os tipos de entrada numérica, como inteiros e decimais, podem ser validados em relação aos limites superior e inferior aceitáveis. Ao combinar entradas de várias fontes, a validação deve ser realizada durante a concatenação e não apenas em relação aos elementos de dados individuais. Essa prática ajuda a evitar situações em que a validação de entrada pode ser bem-sucedida quando executada em itens de dados individuais, mas falha quando feita em um conjunto combinado de todas as fontes.</desc>
	<solution>Fase: Arquitetura e Design.
Use um framework de validação de entrada, como Struts ou a API de validação OWASP ESAPI.

Compreenda todas as potenciais áreas onde entradas de dados não confiáveis podem ser inseridas em seu software: parâmetros ou argumentos, cookies, qualquer coisa lida a partir da rede, variáveis de ambiente, pesquisas de DNS reverso, resultados de consultas, cabeçalhos de solicitações, componentes de URLs, e-mails, arquivos, bancos de dados e quaisquer sistemas externos que forneçam dados para a aplicação. Lembre-se de que essas entradas podem ser obtidas indiretamente por meio de chamadas de API.

Para qualquer verificação de segurança executada no lado do cliente, certifique-se de que essas verificações sejam duplicadas no lado do servidor. Invasores podem ignorar as verificações do lado do cliente, modificando os valores após a realização das verificações ou alterando o cliente para remover as verificações do lado do cliente completamente. Em seguida, esses valores modificados poderiam ser enviados ao servidor.

Mesmo que as verificações do lado do cliente forneçam benefícios mínimos em relação à segurança do lado do servidor, elas ainda são úteis. Primeiro, elas podem oferecer suporte à detecção de intrusão. Se o servidor receber uma entrada de dados que deveria ter sido rejeitada pelo cliente, isso pode ser uma indicação de um ataque em curso. Em segundo lugar, a verificação de erros do lado do cliente pode fornecer feedback útil ao usuário sobre as expectativas de entrada válida. Em terceiro lugar, pode haver uma redução no tempo de processamento do lado do servidor para erros de entrada acidentais, embora normalmente isso seja uma pequena economia.

Não dependa exclusivamente da validação da lista de negação para detectar entradas maliciosas ou codificar a saída. Existem muitas maneiras de codificar o mesmo caractere, então é provável que você perca algumas variantes.

Quando sua aplicação combinar dados de várias fontes, execute a validação após as fontes terem sido combinadas. Os elementos de dados individuais podem passar na etapa de validação, mas violam as restrições pretendidas após terem sido combinados.

Presuma que toda a entrada de dados é maliciosa. Use uma estratégia de validação de entrada "aceita como boa", ou seja, use uma lista de permissões de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Não confie exclusivamente na procura de entradas maliciosas ou malformadas (ou seja, não confie em uma lista de negação). No entanto, as listas de negação podem ser úteis para detectar ataques em potencial ou determinar quais entradas estão tão malformadas que devem ser rejeitadas imediatamente.

Ao executar a validação de entradas de dados, considere todas as propriedades potencialmente relevantes, incluindo comprimento, tipo de entrada, a gama completa de valores aceitáveis, entradas ausentes ou extras, sintaxe, consistência entre campos relacionados e conformidade com as regras de negócios. Como um exemplo de lógica de regra de negócios, "barco" pode ser sintaticamente válido porque contém apenas caracteres alfanuméricos, mas não é válido se você estiver esperando cores como "vermelho" ou "azul".

Fase: Implementação

Seja especialmente cuidadoso ao validar sua entrada ao invocar o código que cruza os limites da linguagem, como de uma linguagem interpretada para um código nativo. Isso pode criar uma interação inesperada entre os limites da linguagem. Certifique-se de que você não está violando nenhuma das expectativas da linguagem com a qual está interfaceando. Por exemplo, mesmo que o Java não seja suscetível a estouros de buffer, fornecer um argumento enorme em uma chamada ao código nativo pode disparar um estouro.

Converta diretamente seu tipo de entrada no tipo de dados esperado, como usar uma função de conversão que converte uma string em um número. Depois de converter para o tipo de dados esperado, certifique-se de que os valores de entrada estejam dentro da faixa esperada de valores permitidos e que as consistências de vários campos sejam mantidas.

As entradas de dados devem ser decodificadas e canonizadas para a representação interna atual da aplicação antes de serem validadas. Certifique-se de que sua aplicação não decodifique inadvertidamente a mesma entrada duas vezes. Esses erros podem ser usados para contornar os esquemas de lista de permissões, introduzindo entradas perigosas após terem sido verificados. Use bibliotecas como o controle OWASP ESAPI Canonicalization.

Considere realizar canonização repetida até que sua entrada de dados não mude mais. Isso evitará decodificação dupla e cenários semelhantes, mas pode modificar inadvertidamente entradas que podem conter conteúdo perigoso codificado corretamente.

Ao trocar dados entre componentes, certifique-se de que ambos os componentes estejam usando a mesma codificação de caracteres. Certifique-se de que a codificação adequada seja aplicada a cada interface. Defina explicitamente a codificação que está usando sempre que o protocolo permitir.</solution>
	<reference>http://projects.webappsec.org/Improper-Input-Handling</reference>
	<reference>http://cwe.mitre.org/data/definitions/89.html</reference>
</vuln_item_wasc_20>

<vuln_items>wasc_21</vuln_items>
<vuln_item_wasc_21>
	<alert>Anti-Automação Insuficiente</alert>
	<desc>Anti-Automação Insuficiente ocorre quando uma aplicação web permite que um invasor automatize um processo que foi originalmente projetado para ser executado apenas de forma manual, ou seja, por um usuário humano da web.


As funcionalidades de aplicações web que costumam ser alvo de ataques de automação podem incluir:
* - Formulários de login da aplicação - os invasores podem automatizar solicitações de login de força bruta na tentativa de adivinhar as credenciais do usuário;
* - Formulários de registro de serviço - os invasores podem criar automaticamente milhares de novas contas;
* - Formulários de e-mail - os invasores podem explorar os formulários de e-mail como retransmissores de spam ou para inundar a caixa de correio de um determinado usuário;
* - Manutenção de conta - os invasores podem executar DoS em massa contra uma aplicação, inundando-o com inúmeras solicitações para desativar ou excluir contas de usuário;
* - Formulários de informações de conta - os invasores podem realizar tentativas em massa de coletar informações pessoais do usuário de uma aplicação da web;
* - Formulários de comentários/formulários de envio de conteúdo - podem ser usados ​​para enviar spam para blogs, fóruns da web e quadros de avisos da web, enviando automaticamente conteúdos como spam ou mesmo malware baseado na web;
* - Formulários vinculados a consultas de banco de dados SQL - podem ser explorados para executar um ataque de negação de serviço contra a aplicação. O ataque é executado enviando várias consultas SQL pesadas em um curto período de tempo, impedindo, portanto, o serviço de usuários reais;
    
* - eShopping / eCommerce - aplicações de eShopping e eCommerce que não exigem compradores exclusivamente humanos, podem ser explorados para comprar itens preferenciais em grandes quantidades, como ingressos para eventos esportivos. Posteriormente, são vendidos por cambistas por preços mais elevados;
    
* - Enquetes online - enquetes e outros tipos de sistemas de votação online podem ser automaticamente subvertidos em favor de uma certa escolha;
    
* - Envio de mensagens SMS baseado na Web - os invasores podem explorar sistemas de envio de mensagens SMS para enviar spam para usuários de telefones celulares.
	</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Insufficient+Anti-automation</reference>
	<reference>http://cwe.mitre.org/data/definitions/116.html</reference>
</vuln_item_wasc_21>

<vuln_items>wasc_22</vuln_items>
<vuln_item_wasc_22>
	<alert>Tratamento Inadequado de Saída</alert>
	<desc>O tratamento de saída se refere a como uma aplicação gera dados de saída.  Se uma aplicação tiver tratamento inadequado de saída, os dados de saída podem ser consumidos levando a vulnerabilidades e ações nunca pretendidas pelo desenvolvedor da aplicação.  Em muitos casos, essa interpretação não intencional é classificada como uma ou mais formas de vulnerabilidades críticas de aplicações.

Qualquer local onde os dados saem de um limite de aplicativo pode estar sujeito ao tratamento inadequado de saída.  Os limites da aplicação existem onde os dados saem de um contexto e entram em outro.  Isso inclui aplicativos passando dados para outros aplicativos por meio de serviços da web, sockets, linha de comando, variáveis ambientais, etc... Também inclui a passagem de dados entre camadas dentro de uma arquitetura de aplicativo, como um banco de dados, servidor de diretório, interpretador HTML/Java Script (navegador ) ou sistema operacional.  Mais detalhes sobre onde pode ocorrer o tratamento inadequado de saída podem ser encontrados na seção abaixo intitulada "Locais Comuns de Saída de Dados".

O tratamento inadequado de saída pode assumir várias formas dentro de uma aplicação.  Essas formas podem ser categorizadas em: erros de protocolo, erros de aplicação e erros relacionados ao consumidor de dados.  Erros de protocolo incluem codificação de saída incorreta ou ausente ou escape e saída de dados inválidos.  Os erros de aplicação incluem erros de lógica, como saída de dados incorretos ou transmissão de conteúdo malicioso não filtrado.  Se a aplicação não distinguir adequadamente o conteúdo legítimo do ilegítimo, ou não contornar vulnerabilidades conhecidas no consumidor de dados, isso pode resultar em abuso do consumidor de dados causado pelo manuseio incorreto da saída.

Uma aplicação que não fornece dados no contexto correto pode permitir que um invasor abuse do consumidor de dados.  Isso pode levar a ameaças específicas referenciadas na Classificação de Ameaças WASC, incluindo Falsificação de Conteúdo, Cross-Site Scripting (XSS), Divisão de Resposta HTTP, Contrabando de Resposta HTTP, Injeção de LDAP, Comandos de Sistema Operacional, Desvio de Roteamento, Violação de SOAP Array, Redirecionador de URLs, Injeção de XML, Injeção XQuery, Injeção XPath, Injeção Mail Command, Injeção NULL e Injeção SQL.

O tratamento adequado da saída evita a interpretação inesperada ou não intencional dos dados pelo consumidor.  Para atingir esse objetivo, os desenvolvedores devem entender o modelo de dados da aplicação, como os dados serão consumidos por outras partes dela e como serão apresentados ao usuário.  As técnicas para garantir o tratamento adequado da saída incluem, mas não se limitam à filtragem e sanitização dos dados (mais detalhes sobre a sanitização e a filtragem da saída podem ser encontrados nas seções com títulos apropriados abaixo).  No entanto, o uso inconsistente de técnicas de tratamento de saída selecionadas pode realmente aumentar o risco de tratamento inadequado de saída se os dados de saída forem negligenciados ou deixados sem tratamento.  Para garantir "defesa em profundidade", os desenvolvedores devem presumir que todos os dados em uma aplicação não são confiáveis ao escolher as estratégias de tratamento de saída apropriadas.

Embora o tratamento de saída adequado possa assumir muitas formas diferentes, uma aplicação não pode ser segura a menos que ela proteja contra interpretações não intencionais pelo consumidor de dados. Este requisito básico é essencial para que uma aplicação controle as operações de saída com segurança.</desc>
	<solution>Use uma biblioteca verificada ou framework que não permita que essa vulnerabilidade ocorra, ou forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.

Por exemplo, considere usar o controle ESAPI Encoding ou uma ferramenta, biblioteca ou framework semelhante. Isso ajudará o desenvolvedor a codificar as saídas de uma maneira menos sujeita a erros.

Como alternativa, use funções integradas, mas considere o uso de wrappers, caso seja descoberto que essas funções têm uma vulnerabilidade.

Se disponível, use mecanismos estruturados que impõem automaticamente a separação entre dados e código. Esses mecanismos podem ser capazes de fornecer citação, codificação e validação relevantes automaticamente, em vez de depender do desenvolvedor para fornecer esse recurso em cada ponto onde a saída é gerada.

Por exemplo, stored procedures podem reforçar a estrutura de consulta do banco de dados e reduzir a probabilidade de Injeção SQL.

Compreenda o contexto no qual seus dados serão usados e a codificação que será esperada. Isso é especialmente importante ao transmitir dados entre componentes diferentes ou ao gerar saídas que podem conter várias codificações ao mesmo tempo, como páginas da web ou mensagens de e-mail com várias partes. Estude todos os protocolos de comunicação e representações de dados esperados para determinar as estratégias de codificação necessárias.

Em alguns casos, a validação de entrada pode ser uma estratégia importante quando a codificação de saída não é uma solução completa. Por exemplo, você pode estar fornecendo a mesma saída que será processada por vários consumidores que usam codificações ou representações diferentes. Em outros casos, pode ser necessário permitir que a entrada fornecida pelo usuário contenha informações de controle, como tags HTML limitadas que oferecem suporte à formatação em um wiki ou quadro de avisos. Quando esse tipo de requisito deve ser atendido, use uma lista de permissões extremamente restrita para limitar quais sequências de controle podem ser usadas. Verifique se a estrutura sintática resultante é a que você espera. Use seus métodos normais de codificação para o restante da entrada.

Use a validação de entrada como uma medida de defesa em profundidade para reduzir a probabilidade de erros de codificação de saída (consulte a CWE-20).

Ao trocar dados entre componentes, certifique-se de que ambos os componentes estejam usando a mesma codificação de caracteres. Certifique-se de que a codificação adequada seja aplicada a cada interface. Defina explicitamente a codificação que está usando sempre que o protocolo permitir.</solution>
	<reference>http://projects.webappsec.org/Improper-Output-Handling</reference>
	<reference/>
</vuln_item_wasc_22>

<vuln_items>wasc_23</vuln_items>
<vuln_item_wasc_23>
	<alert>Injeção XML</alert>
	<desc>Injeção XML (XML Injection) é uma técnica de ataque usada para manipular ou comprometer a lógica de uma aplicação ou serviço XML. A injeção de conteúdo e/ou estruturas XML não intencionais em uma mensagem XML pode alterar a lógica pretendida da aplicação. Além disso, a injeção de XML pode causar a inserção de conteúdo malicioso na mensagem/documento resultante.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/XML-Injection</reference>
	<reference/>
</vuln_item_wasc_23>

<vuln_items>wasc_24</vuln_items>
<vuln_item_wasc_24>
	<alert>Divisão de Solicitação HTTP</alert>
	<desc>A Divisão de Solitiação HTTP (HTTP Request Splitting) é um ataque que permite forçar o navegador a enviar solicitações HTTP arbitrárias, infligindo XSS e envenenando o cache do navegador. A essência do ataque é a capacidade do invasor, uma vez que a vítima (navegador) é forçada a carregar a página HTML maliciosa do invasor, de manipular uma das funções do navegador para enviar 2 solicitações HTTP ao invés de apenas 1. Dois desses mecanismos foram explorados até agora: o objeto XmlHttpRequest (abreviado como XHR) e o mecanismo de autenticação HTTP digest. Para que esse ataque funcione, o navegador deve usar um proxy HTTP de encaminhamento (nem todos "suportam" esse ataque), ou o ataque deve ser realizado contra um host localizado no mesmo IP (da perspectiva do navegador) do invasor máquina.</desc>
	<solution>Evite usar CRLF como uma sequência especial.

Filtre ou cite apropriadamente as sequências CRLF na entrada controlada pelo usuário.</solution>
	<reference>http://projects.webappsec.org/HTTP-Request-Splitting</reference>
	<reference>http://cwe.mitre.org/data/definitions/93.html</reference>
</vuln_item_wasc_24>

<vuln_items>wasc_25</vuln_items>
<vuln_item_wasc_25>
	<alert>Divisão de Resposta HTTP</alert>
	<desc>No ataque de Divisão de Resposta HTTP (Divisão de Resposta HTTP), sempre há 3 partes (pelo menos) envolvidas:
* - Servidor Web, que possui uma falha de segurança que permite a divisão de resposta HTTP;
* - Alvo - uma entidade que interage com o servidor da web, talvez em nome do invasor. Normalmente, é um servidor de cache (proxy de encaminhamento/reverso) ou um navegador (possivelmente com um cache de navegador);
    
* - Atacante - inicia o ataque.

A essência da Divisão de Resposta HTTP é a capacidade do invasor de enviar uma única solicitação HTTP que força o servidor da web a formar um fluxo de saída, que é então interpretado pelo destino como duas respostas HTTP em vez de uma resposta, no caso normal. A primeira resposta pode ser parcialmente controlada pelo invasor, mas isso é menos importante. O que realmente importa é que o invasor controla completamente a forma da segunda resposta da linha de status HTTP, até o último byte do seu corpo. Assim que isso for possível, o invasor realiza o ataque enviando duas solicitações através do alvo. A primeira invoca duas respostas do servidor web e a segunda solicitação normalmente seria para algum recurso "inocente" no servidor da web. No entanto, a segunda solicitação seria correspondida pelo destino, à segunda resposta HTTP, que é totalmente controlada pelo invasor. O invasor, portanto, engana o alvo fazendo-o acreditar que um determinado recurso no servidor da web (designado pela segunda solicitação) é a resposta HTTP do servidor (conteúdo do servidor), embora sejam, na verdade, alguns dados, que são forjados pelo invasor por meio o servidor web - esta é a segunda resposta.

Os Ataques de Divisão de Resposta HTTP ocorrem quando o script do servidor incorpora dados do usuário em cabeçalhos de resposta HTTP. Normalmente, isso acontece quando o script incorpora dados do usuário na URL de redirecionamento de uma resposta de redirecionamento (código de status HTTP 3xx) ou quando o script incorpora dados do usuário em um valor ou nome de cookie quando a resposta define um cookie.</desc>
	<solution>Construa cabeçalhos HTTP com muito cuidado, evitando o uso de entrada de dados não validados.</solution>
	<reference>http://projects.webappsec.org/HTTP-Response-Splitting</reference>
	<reference>http://cwe.mitre.org/data/definitions/113.html</reference>
</vuln_item_wasc_25>

<vuln_items>wasc_26</vuln_items>
<vuln_item_wasc_26>
	<alert>Contrabando de Solicitação HTTP</alert>
	<desc>O Contrabando de Solicitações HTTP (HTTP Request Smuggling) é uma técnica de ataque que abusa da discrepância na análise de solicitações HTTP não compatíveis com RFC entre dois dispositivos HTTP (normalmente um proxy front-end ou firewall habilitado para HTTP e um servidor web back-end) para contrabandear uma solicitação para o segundo dispositivo "através" do primeiro dispositivo. Essa técnica permite que o invasor envie um conjunto de solicitações para o segundo dispositivo enquanto o primeiro dispositivo vê um conjunto diferente de solicitações. Por sua vez, isso facilita várias possíveis explorações, como envenenamento parcial do cache, contornando a proteção de firewall e XSS.</desc>
	<solution>Use um servidor da web que empregue um procedimento de análise HTTP estrito, como o Apache (consulte o artigo de referência).

Use apenas comunicação SSL.

Encerre a sessão do cliente após cada solicitação.

Transforme todas as páginas para não armazenáveis em cache (não-cacheáveis).</solution>
	<reference>http://projects.webappsec.org/HTTP-Request-Smuggling</reference>
	<reference>http://cwe.mitre.org/data/definitions/444.html</reference>
</vuln_item_wasc_26>

<vuln_items>wasc_27</vuln_items>
<vuln_item_wasc_27>
	<alert>Contrabando de Resposta HTTP</alert>
	<desc>O Contrabando de Resposta HTTP (HTTP Response Smuggling) é uma técnica para "contrabandear" 2 respostas HTTP de um servidor para um cliente, por meio de um dispositivo HTTP intermediário que espera (ou permite) uma única resposta do servidor.

Um uso para essa técnica é aprimorar a técnica de divisão de resposta HTTP básica para evitar contra-medidas de divisão de resposta HTTP. Nesse caso, o intermediário é o mecanismo de anti-divisão de resposta HTTP entre o servidor da web e o servidor proxy (ou navegador da web). Outro caso de uso é falsificar as respostas recebidas pelo navegador. Nesse caso, um site malicioso fornece ao navegador uma página que o navegador interpretará como originária de um domínio (alvo) diferente. O contrabando de resposta HTTP pode ser usado para conseguir isso quando o navegador usa um servidor proxy para acessar os dois sites.

O contrabando de resposta HTTP faz uso de técnicas semelhantes a contrabando de solicitação HTTP para explorar as discrepâncias entre o que um mecanismo de divisão de resposta HTTP (ou um servidor proxy) consideraria ser o fluxo de resposta HTTP e o fluxo de resposta analisado por um servidor proxy (ou um navegador). Assim, embora um mecanismo de anti-divisão de resposta HTTP possa considerar um fluxo de resposta específico inofensivo (resposta HTTP única), um proxy/navegador ainda pode analisá-lo como duas respostas HTTP e portanto, ser suscetível a todos os resultados da técnica de divisão de resposta HTTP original (no primeiro caso de uso) ou ser suscetível a falsificação de página (no segundo caso). Por exemplo, alguns mecanismos de anti-divisão de resposta HTTP em uso por alguns engines de aplicação, a proíbem de inserir um cabeçalho contendo CR+LF na resposta. Ainda assim, um invasor pode forçar a aplicação a inserir um cabeçalho contendo CRs, contornando assim o mecanismo de defesa. Alguns servidores proxy ainda podem tratar CR (apenas) como um separador de cabeçalho (e resposta) e, como tal, a combinação de servidor web e servidor proxy ainda estará vulnerável a um ataque que pode envenenar o cache do proxy.
	</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/HTTP-Response-Smuggling</reference>
	<reference/>
</vuln_item_wasc_27>

<vuln_items>wasc_28</vuln_items>
<vuln_item_wasc_28>
	<alert>Injeção de Byte Nulo</alert>
	<desc>A Injeção de Byte Nulo (Null Byte Injection) é uma técnica de exploração ativa usada para contornar os filtros de verificação de integridade na infraestrutura na web, adicionando caracteres de byte nulo codificados por URL (ou seja, %00 ou 0x00 em hexadecimal) aos dados fornecidos pelo usuário. Este processo de injeção pode alterar a lógica pretendida para a aplicação e permitir que adversários mal-intencionados obtenham acesso não autorizado aos arquivos do sistema.

A maioria dos aplicativos da web hoje é desenvolvida usando linguagens de alto nível, como PHP, ASP, Perl e Java. No entanto, esses aplicativos da web em algum ponto requerem processamento de código de alto nível no nível do sistema e este processo é geralmente realizado usando funções ‘C/C++’. A natureza diversa dessas tecnologias dependentes resultou em uma classe de ataque chamada de ataque "Null Byte Injection" (Injeção de Byte Nulo) ou "Null Byte Poisoning" (Envenenamento por Byte Nulo). Em C/C++, um byte nulo representa o ponto de terminação da string ou caractere delimitador, o que significa interromper o processamento da string imediatamente. Bytes após o delimitador serão ignorados. Se a string perder seu caractere nulo, o comprimento de uma string se tornará desconhecido até que o ponteiro de memória encontre o próximo byte zero. Essa ramificação não intencional pode causar um comportamento incomum e introduzir vulnerabilidades no sistema ou no escopo da aplicação. Em outras palavras, várias linguagens de nível superior tratam o ‘byte nulo’ como um marcador para o comprimento da string, uma vez que não tem nenhum significado especial em seu contexto. Devido a essa diferença de interpretação, bytes nulos podem ser facilmente injetados para manipular o comportamento da aplicação.

URLs são limitadas a um conjunto de caracteres US-ASCII variando de 0x20 a 0x7E (hex) ou 32 a 126 (decimal). No entanto, o intervalo acima mencionado usa vários caracteres que não são permitidos porque têm um significado especial no contexto do protocolo HTTP. Por esse motivo, o esquema de codificação de URL foi introduzido para incluir caracteres especiais na URL usando a representação de caracteres ASCII estendida. Em termos de “byte nulo”, isso é representado como %00 em hexadecimal. O escopo de um ataque de byte nulo começa onde as aplicações web interagem com rotinas 'C' ativas e APIs externas do sistema operacional subjacente. Portanto, permite que um invasor manipule recursos da web pela leitura ou gravação de arquivos com base nos privilégios de usuário da aplicação.</desc>
	<solution>Os desenvolvedores devem prever que caracteres nulos ou bytes nulos serão injetados/removidos/manipulados nos vetores de entrada de seu sistema de software. Use uma combinação apropriada de blacklists/listas negras/negativadas e whitelists/listas brancas/de permissões para garantir que apenas entradas válidas, esperadas e apropriadas sejam processadas pelo sistema.

Presuma que toda a entrada de dados é maliciosa. Use um mecanismo de validação de entrada padrão para validar todas as entradas quanto ao comprimento, tipo, sintaxe e regras de negócios antes de aceitar os dados a serem exibidos ou armazenados. Use uma estratégia de validação conhecida e "aceita como boa/válida".

Use e especifique uma codificação de saída forte (como ISO 8859-1 ou UTF 8).

Não dependa exclusivamente da validação da lista de negação para detectar entradas maliciosas ou codificar a saída. Existem muitas variantes para codificar um caractere; é provável que você perca algumas delas.

As entradas de dados devem ser decodificadas e canonizadas para a representação interna atual da aplicação antes de serem validadas. Certifique-se de que sua aplicação não decodifique a mesma entrada duas vezes. Esses erros podem ser usados para contornar os esquemas de lista de permissões, introduzindo entradas perigosas após terem sido verificados.</solution>
	<reference>http://projects.webappsec.org/Null-Byte-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/158.html</reference>
</vuln_item_wasc_28>

<vuln_items>wasc_29</vuln_items>
<vuln_item_wasc_29>
	<alert>Injeção LDAP</alert>
	<desc>Injeção LDAP (LDAP Injection) é uma técnica de ataque usada para explorar sites que constroem instruções LDAP a partir de entradas fornecidas pelo usuário.

O protocolo LDAP (Lightweight Directory Access Protocol) é um protocolo de padrão aberto para consulta e manipulação de serviços de diretório X.500. O protocolo LDAP é executado em protocolos de transporte da Internet, como o TCP. As aplicações web podem usar entradas fornecidas pelo usuário para criar instruções LDAP personalizadas para solicitações de páginas web dinâmicas.

Quando uma aplicação web falha em limpar adequadamente a entrada fornecida pelo usuário, é possível que um invasor altere a construção de uma instrução LDAP. Quando um invasor é capaz de modificar uma instrução LDAP, o processo será executado com as mesmas permissões do componente que executou o comando. (por exemplo, servidor de banco de dados, servidor de aplicações web, servidor web, etc). Isso pode causar sérios problemas de segurança onde as permissões concedem os direitos de consultar, modificar ou remover qualquer coisa dentro da árvore LDAP. As mesmas técnicas de exploração avançada disponíveis no SQL Injection também podem ser aplicadas de forma semelhante na LDAP Injection.</desc>
	<solution>Presuma que toda a entrada de dados é maliciosa. Use uma combinação apropriada de listas negativas e listas permissivas para neutralizar a sintaxe LDAP da entrada controlada pelo usuário.</solution>
	<reference>http://projects.webappsec.org/LDAP-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/90.html</reference>
</vuln_item_wasc_29>

<vuln_items>wasc_30</vuln_items>
<vuln_item_wasc_30>
	<alert>Injeção Mail Command</alert>
	<desc>Injeção Mail Command (Mail Command Injection) é uma técnica de ataque usada para explorar servidores de e-mail e aplicativos de webmail que constroem instruções IMAP/SMTP a partir de entradas fornecidas pelo usuário que não são devidamente higienizadas. Dependendo do tipo de instrução aproveitada pelo invasor, encontramos dois tipos de injeções: IMAP e SMTP Injection. Uma injeção IMAP/SMTP pode possibilitar o acesso a um servidor de e-mail ao qual anteriormente não se tinha acesso. Em alguns casos, esses sistemas internos não têm o mesmo nível de proteção de segurança de infraestrutura aplicado a eles como a maioria dos servidores web front-end. Portanto, os invasores podem descobrir se o servidor de e-mail produz melhores resultados em termos de exploração. Por outro lado, esta técnica permite contornar possíveis restrições que possam existir ao nível da aplicação (CAPTCHA, número máximo de requisições, etc).</desc>
	<solution>Compreenda todas as potenciais áreas onde entradas de dados não confiáveis podem ser inseridas em seu software: parâmetros ou argumentos, cookies, qualquer coisa lida a partir da rede, variáveis de ambiente, cabeçalhos de solicitações bem como conteúdo, componentes de URLs, e-mails, arquivos, bancos de dados e quaisquer sistemas externos que forneçam dados para a aplicação. Execute a validação de entradas de dados em interfaces bem definidas.

Presuma que toda a entrada de dados é maliciosa. Use uma estratégia de validação de entrada "aceita como boa" (ou seja, use uma lista de permissões). Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Use uma lista de negação para rejeitar qualquer entrada inesperada e detectar ataques potenciais.

Não dependa exclusivamente da validação da lista de negação para detectar entradas maliciosas ou codificar a saída. Existem muitas maneiras de codificar o mesmo caractere, então é provável que você perca algumas variantes.

Converta diretamente seu tipo de entrada no tipo de dados esperado, como usar uma função de conversão que converte uma string em um número. Depois de converter para o tipo de dados esperado, certifique-se de que os valores de entrada estejam dentro da faixa esperada de valores permitidos e que as consistências de vários campos sejam mantidas.

As entradas de dados devem ser decodificadas e canonizadas para a representação interna atual da aplicação antes de serem validadas. Certifique-se de que sua aplicação não decodifique inadvertidamente a mesma entrada duas vezes. Esses erros podem ser usados para contornar os esquemas de lista de permissões, introduzindo entradas perigosas após terem sido verificados. Use bibliotecas como o controle OWASP ESAPI Canonicalization.

Considere realizar canonização repetida até que sua entrada de dados não mude mais. Isso evitará decodificação dupla e cenários semelhantes, mas pode modificar inadvertidamente entradas que podem conter conteúdo perigoso codificado corretamente.

Ao trocar dados entre componentes, certifique-se de que ambos os componentes estejam usando a mesma codificação de caracteres. Certifique-se de que a codificação adequada seja aplicada a cada interface. Defina explicitamente a codificação que está usando sempre que o protocolo permitir.

Quando sua aplicação combinar dados de várias fontes, execute a validação após as fontes terem sido combinadas. Os elementos de dados individuais podem passar na etapa de validação, mas violam as restrições pretendidas após terem sido combinados.</solution>
	<reference>http://projects.webappsec.org/Mail-Command-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/88.html</reference>
</vuln_item_wasc_30>

<vuln_items>wasc_31</vuln_items>
<vuln_item_wasc_31>
	<alert>Comandos de Sistema Operacional</alert>
	<desc>Comandos de Sistema Operacional (OS Commanding) é uma técnica de ataque usada para execução não autorizada de comandos do sistema operacional.

O OS Commanding é o resultado direto da combinação de código confiável e dados não confiáveis. Este ataque é possível quando uma aplicação aceita entrada não confiável para construir comandos de sistema operacional de uma forma insegura, envolvendo sanitização de dados imprópria e/ou chamadas imprópria a programas externos. No OS Commanding, os comandos executados por um invasor serão executados com os mesmos privilégios do componente que executou o comando (por exemplo, servidor de banco de dados, servidor de aplicção web, servidor web, wrapper, aplicação). Como os comandos são executados com os privilégios do componente em execução, um invasor pode aproveitar isso para obter acesso ou danificar partes que, de outra forma, seriam inacessíveis (por exemplo, diretórios e arquivos do sistema operacional).</desc>
	<solution>Se possível, use chamadas de biblioteca em vez de processos externos para recriar a funcionalidade desejada.

Execute seu código em uma "jail" ou ambiente sandbox similar que imponha limites estritos entre o processo e o sistema operacional. Isso pode restringir efetivamente quais arquivos podem ser acessados em um determinado diretório ou quais comandos podem ser executados por seu software.

Exemplos em nível de sistemas operacionais incluem Chroot Jail do Unix, AppArmor e SELinux. Em geral, código gerenciado pode fornecer alguma proteção. Por exemplo, java.io.FilePermission no Java SecurityManager permite especificar restrições nas operações de arquivo.
Essa pode não ser uma solução viável e apenas limita o impacto no sistema operacional; o restante de seu aplicativo ainda pode estar sujeito a comprometimento.

Para quaisquer dados que serão usados para gerar um comando a ser executado, mantenha-os o máximo possível fora do controle externo. Por exemplo, em aplicações web, isso pode exigir o armazenamento do comando localmente no estado da sessão, em vez de enviá-lo ao cliente em um campo de formulário oculto.

Use uma biblioteca verificada ou framework que não permita que essa vulnerabilidade ocorra, ou forneça construções/implementações que tornem essa vulnerabilidade mais fácil de evitar.

Por exemplo, considere usar o controle ESAPI Encoding ou uma ferramenta, biblioteca ou framework semelhante. Isso ajudará o desenvolvedor a codificar as saídas de uma maneira menos sujeita a erros.

Se você precisar usar strings de consulta ou comandos gerados dinamicamente apesar do risco, cite corretamente os argumentos e retire quaisquer caracteres especiais dentro desses argumentos. A abordagem mais conservadora é escapar ou filtrar todos os caracteres que não passam em uma lista de permissões extremamente restrita (como tudo que não é alfanumérico ou espaço em branco). Se alguns caracteres especiais ainda forem necessários, como espaço em branco, coloque cada argumento entre aspas após a etapa de escape/filtragem. Tenha cuidado com a injeção de argumentos (CWE-88).

Se o programa a ser executado permite que os argumentos sejam especificados dentro de um arquivo de entrada ou da entrada padrão, considere usar esse modo para passar argumentos em vez da linha de comando.

Se disponível, use mecanismos estruturados que impõem automaticamente a separação entre dados e código. Esses mecanismos podem ser capazes de fornecer citação, codificação e validação relevantes automaticamente, em vez de depender do desenvolvedor para fornecer esse recurso em cada ponto onde a saída é gerada.

Algumas linguagens oferecem várias funções que podem ser usadas para invocar comandos. Sempre que possível, identifique qualquer função que invoque um shell de comando usando uma única string e substitua-a por uma função que requer argumentos individuais. Essas funções normalmente executam citações apropriadas e filtragem de argumentos. Por exemplo, em C, a função system() aceita uma string que contém todo o comando a ser executado, enquanto execl(), execve() e outros requerem uma matriz de strings, uma para cada argumento. No Windows, CreateProcess() aceita apenas um comando por vez. Em Perl, se system() é fornecido com um array de argumentos, ele irá citar cada um dos argumentos.

Presuma que toda a entrada de dados é maliciosa. Use uma estratégia de validação de entrada "aceita como boa", ou seja, use uma lista de permissões de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Não confie exclusivamente na procura de entradas maliciosas ou malformadas (ou seja, não confie em uma lista de negação). No entanto, as listas de negação podem ser úteis para detectar ataques em potencial ou determinar quais entradas estão tão malformadas que devem ser rejeitadas imediatamente.

Ao executar a validação de entradas de dados, considere todas as propriedades potencialmente relevantes, incluindo comprimento, tipo de entrada, a gama completa de valores aceitáveis, entradas ausentes ou extras, sintaxe, consistência entre campos relacionados e conformidade com as regras de negócios. Como um exemplo de lógica de regra de negócios, "barco" pode ser sintaticamente válido porque contém apenas caracteres alfanuméricos, mas não é válido se você estiver esperando cores como "vermelho" ou "azul".

Ao construir strings de comando do sistema operacional, use listas de permissão rigorosas que limitam o conjunto de caracteres com base no valor esperado do parâmetro na solicitação. Isso limitará indiretamente o escopo de um ataque, mas essa técnica é menos importante do que a codificação de saída adequada e o escape.

Observe que a codificação de saída, escape e citação adequados são a solução mais eficaz para evitar a injeção de comandos de sistema operacional, embora a validação de entrada possa fornecer alguma defesa em profundidade. Isso ocorre porque ele limita efetivamente o que aparecerá na saída. A validação de entrada nem sempre impedirá a injeção comandos de sistema operacional, especialmente se você precisar oferecer suporte a campos de texto de formato livre que podem conter caracteres arbitrários. Por exemplo, ao invocar um programa de e-mail, você pode precisar permitir que o campo de assunto contenha entradas perigosas, como os caracteres ";" e ">", que precisariam ser escapados/filtrados ou manipulados de outra forma. Nesse caso, retirar o caractere pode reduzir o risco de injeção de comando de sistema operacional, mas produziria um comportamento incorreto porque o campo do assunto não seria registrado como o usuário pretendia. Isso pode parecer um pequeno inconveniente, mas pode ser mais importante quando o programa depende de linhas de assunto bem estruturadas para passar mensagens para outros componentes.

Mesmo se você cometer um erro em sua validação (como esquecer um em cada 100 campos de entrada), a codificação apropriada provavelmente o protegerá de ataques baseados em injeção. Contanto que não seja feito isoladamente, a validação de entrada ainda é uma técnica útil, pois pode reduzir significativamente a superfície de ataque, permitir que você detecte alguns ataques e fornecer outros benefícios de segurança que a codificação adequada não aborda.</solution>
	<reference>http://projects.webappsec.org/OS-Commanding</reference>
	<reference>http://cwe.mitre.org/data/definitions/78.html</reference>
</vuln_item_wasc_31>

<vuln_items>wasc_32</vuln_items>
<vuln_item_wasc_32>
	<alert>Desvio de Roteamento</alert>
	<desc>O WS-Routing Protocol (WS-Routing) é um protocolo para troca de mensagens SOAP de um remetente de mensagem inicial para um receptor final, normalmente por meio de um conjunto de intermediários. O protocolo WS-Routing é implementado como uma extensão SOAP e está integrado no cabeçalho SOAP. O WS-Routing é freqüentemente usado para fornecer uma maneira de direcionar o tráfego XML por meio de ambientes e transações complexos, permitindo que estações intermediárias temporárias no caminho XML atribuam instruções de roteamento a um documento XML.

Os desvios de roteamento são um tipo de ataque "Man in the Middle", em que intermediários podem ser injetados ou "sequestrados" para encaminhar mensagens confidenciais para um local externo. As informações de roteamento (no cabeçalho HTTP ou no cabeçalho WS-Routing) podem ser modificadas no caminho e os rastreamentos do roteamento podem ser removidos do cabeçalho e da mensagem de forma que a aplicação receptora não saiba que ocorreu um desvio de roteamento. O cabeçalho e a inserção de objetos de cabeçalho geralmente são menos protegidos do que a mensagem; isso se deve ao fato de que o cabeçalho é usado para capturar todos os metadados da transação, como autenticação, roteamento, formatação, esquema, canonização, namespaces, etc. Além disso, muitos processos podem estar envolvidos na adição/processamento do cabeçalho de um documento XML. Em muitas implementações, as informações de roteamento podem vir de um serviço da web externo (usando WS-Referral, por exemplo) que fornece o roteamento específico para a transação.

WS-Addressing é um padrão mais recente publicado pelo W3C para fornecer funcionalidade de roteamento para mensagens SOAP. Uma das principais diferenças entre WS-Routing e WS-Addressing é que WS-Addressing fornece apenas a próxima localização na rota. Embora pouca pesquisa tenha sido feita sobre a suscetibilidade do WS-Addressing ao Routing Detour Attack, pelo menos um artigo (consulte a referência #6 abaixo) sugere que o WS-Addressing também é vulnerável ao Routing Detour.</desc>
	<solution>Sempre autentique totalmente ambas as extremidades de qualquer canal de comunicação.

Respeite o princípio da mediação completa.

Um certificado vincula uma identidade a uma chave criptográfica para autenticar uma parte em comunicação. Freqüentemente, o certificado assume a forma criptografada do hash da identidade do assunto, a chave pública e informações como o tempo de emissão ou expiração usando a chave privada do emissor. O certificado pode ser validado decifrando o certificado com a chave pública do emissor. Consulte também cadeias de assinatura de certificado X.509 e a estrutura de certificação PGP.</solution>
	<reference>http://projects.webappsec.org/Routing-Detour</reference>
	<reference>http://cwe.mitre.org/data/definitions/300.html</reference>
</vuln_item_wasc_32>

<vuln_items>wasc_33</vuln_items>
<vuln_item_wasc_33>
	<alert>Travessia/Passagem de Caminho</alert>
	<desc>A técnica de ataque de Travessia/Passagem de Caminho (Path Traversal) permite que um invasor acesse arquivos, diretórios e comandos que potencialmente residem fora do diretório raiz do documento da web. Um invasor pode manipular uma URL de forma que o site execute ou revele o conteúdo de arquivos arbitrários em qualquer lugar do servidor. Qualquer dispositivo que exponha uma interface baseada em HTTP é potencialmente vulnerável ao Path Traversal.

A maioria dos sites restringe o acesso do usuário a uma parte específica do sistema de arquivos, normalmente chamada de diretório "raiz do documento web" ou "raiz CGI". Esses diretórios contêm os arquivos destinados ao acesso do usuário e o executável necessário para conduzir a funcionalidade da aplicação web. Para acessar arquivos ou executar comandos em qualquer lugar no sistema de arquivos, os ataques Path Traversal utilizarão a capacidade de sequências de caracteres especiais.

O ataque Path Traversal mais básico usa a seqüência de caracteres especiais "../" para alterar a localização do recurso solicitada na URL. Embora a maioria dos servidores web populares impeça que essa técnica escape da raiz do documento da web, codificações alternativas da sequência "../" podem ajudar a contornar os filtros de segurança. Essas variações de método incluem codificação Unicode válida e inválida ("..%u2216" ou "..%c0%af") do caractere de barra, caracteres de barra invertida ("..\") em servidores baseados em Windows, caracteres codificados por URL "%2e%2e%2f") e codificação de URL dupla ("..%255c") do caractere de barra invertida.

Mesmo que o servidor web restrinja adequadamente as tentativas de Path Traversal no caminho da URL, uma aplicação web em si ainda pode ser vulnerável devido ao tratamento impróprio de entrada de dados fornecida pelo usuário. Este é um problema comum de aplicações web que usam mecanismos de modelo ou carregam texto estático de arquivos. Em variações do ataque, o valor do parâmetro da URL original é substituído pelo nome do arquivo de um dos scripts dinâmicos da aplicação web. Consequentemente, os resultados podem revelar o código-fonte porque o arquivo é interpretado como texto em vez de um script executável. Essas técnicas geralmente empregam caracteres especiais adicionais, como o ponto (".") para revelar a listagem do diretório de trabalho atual ou "% 00" caracteres NULL para ignorar verificações rudimentares de extensão de arquivo.</desc>
	<solution>Presuma que toda a entrada de dados é maliciosa. Use uma estratégia de validação de entrada "aceita como boa", ou seja, use uma lista de permissões de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Não confie exclusivamente na procura de entradas maliciosas ou malformadas (ou seja, não confie em uma lista de negação). No entanto, as listas de negação podem ser úteis para detectar ataques em potencial ou determinar quais entradas estão tão malformadas que devem ser rejeitadas imediatamente.

Ao executar a validação de entradas de dados, considere todas as propriedades potencialmente relevantes, incluindo comprimento, tipo de entrada, a gama completa de valores aceitáveis, entradas ausentes ou extras, sintaxe, consistência entre campos relacionados e conformidade com as regras de negócios. Como um exemplo de lógica de regra de negócios, "barco" pode ser sintaticamente válido porque contém apenas caracteres alfanuméricos, mas não é válido se você estiver esperando cores como "vermelho" ou "azul".

Para nomes de arquivos, use listas de permissões rigorosas que limitam o conjunto de caracteres a ser usado. Se possível, permita apenas um único caractere "." no nome do arquivo para evitar pontos fracos e excluir separadores de diretório, como "/". Use uma lista de permissões de extensões de arquivo permitidas.

Aviso: se você tentar limpar seus dados, faça-o para que o resultado final não esteja em uma forma que pode ser perigosa. Um mecanismo de sanitização pode remover caracteres como '.' e ';' que pode ser necessário para alguns exploits. Um invasor pode tentar enganar o mecanismo de limpeza para "limpar" os dados de uma forma perigosa. Suponha que o invasor injete um '.' dentro de um nome de arquivo (por exemplo, "sensi.tiveFile") e o mecanismo de limpeza remova o caractere resultando em um nome de arquivo válido, "sensitiveFile". Se os dados de entrada agora forem considerados seguros, o arquivo pode estar comprometido. 

As entradas de dados devem ser decodificadas e canonizadas para a representação interna atual da aplicação antes de serem validadas. Certifique-se de que sua aplicação não decodifique a mesma entrada duas vezes. Esses erros podem ser usados para contornar os esquemas de lista de permissões, introduzindo entradas perigosas após terem sido verificados.

Use uma função de canonização de caminho embutida (como por exemplo realpath() em C) que produz a versão canônica do nome do caminho, que remove efetivamente sequências ".." e links simbólicos.

Execute seu código usando os privilégios mais baixos possíveis para realizar as tarefas necessárias. Se possível, crie contas isoladas com privilégios limitados que serão usados apenas para uma única tarefa. Dessa forma, um ataque bem-sucedido não dará ao invasor acesso imediato ao restante do software ou ao seu ambiente. Por exemplo, os aplicativos de banco de dados raramente precisam ser executados como administrador de banco de dados, especialmente nas operações do dia a dia.

Havendo um conjunto de objetos aceitáveis, limitados ou conhecidos como nomes de arquivos ou URLs, crie um mapeamento de um conjunto de valores de entrada fixos (como IDs numéricos) para os nomes de arquivos ou URLs reais e rejeite quaisquer outras entradas.

Execute seu código em uma "jail" ou ambiente sandbox similar que imponha limites estritos entre o processo e o sistema operacional. Isso pode restringir efetivamente quais arquivos podem ser acessados em um determinado diretório ou quais comandos podem ser executados por seu software.

Exemplos em nível de sistemas operacionais incluem Chroot Jail do Unix, AppArmor e SELinux. Em geral, código gerenciado pode fornecer alguma proteção. Por exemplo, java.io.FilePermission no Java SecurityManager permite especificar restrições nas operações de arquivo.

Essa pode não ser uma solução viável e apenas limita o impacto no sistema operacional; o restante de seu aplicativo ainda pode estar sujeito a comprometimento.
</solution>
	<reference>http://projects.webappsec.org/Path-Traversal</reference>
	<reference>http://cwe.mitre.org/data/definitions/22.html</reference>
</vuln_item_wasc_33>

<vuln_items>wasc_34</vuln_items>
<vuln_item_wasc_34>
	<alert>Localização Previsível de Recursos</alert>
	<desc>A Localização Previsível de Recursos é uma técnica de ataque usada para descobrir conteúdos e funcionalidades ocultos em um site. Fazendo suposições via brute force, um invasor pode adivinhar nomes de arquivos e diretórios não destinados à exibição pública. Realizar brute forcing em nomes de arquivos é fácil porque os arquivos/caminhos geralmente têm uma convenção de nomenclatura comum e residem em locais padrão. Isso pode incluir arquivos temporários, arquivos de backup, logs, seções administrativas do site, arquivos de configuração, aplicações de demonstração e arquivos sample. Esses arquivos podem revelar informações confidenciais sobre o site, particularidades internas da aplicação web, informações de banco de dados, senhas, nomes de máquinas, caminhos de arquivo para outras áreas confidenciais, etc...

Isso não apenas ajudará a identificar a superfície de ataque contra o site, o que pode levar a vulnerabilidades adicionais, mas também pode revelar informações valiosas a um invasor sobre o ambiente ou seus usuários. A localização previsível de recursos também é conhecida como Navegação Forçada, Navegação Violenta, Enumeração de Arquivos e Enumeração de Diretórios.</desc>
	<solution>Aplique as autorizações de controle de acesso apropriadas para cada acesso a todos os URLs, scripts ou arquivos restritos.

Considere o uso de estruturas baseadas em MVC, como Struts.</solution>
	<reference>http://projects.webappsec.org/Predictable-Resource-Location</reference>
	<reference>http://cwe.mitre.org/data/definitions/425.html</reference>
</vuln_item_wasc_34>

<vuln_items>wasc_35</vuln_items>
<vuln_item_wasc_35>
	<alert>Violação de SOAP Array</alert>
	<desc>Matrizes de XML SOAP são alvos comuns para ataques maliciosos. Matrizes SOAP são definidos como tendo um tipo de "SOAP-ENC:Array" ou um tipo derivado dela. SOAP arrays têm uma ou mais dimensões (classificação) cujos membros são diferenciados pela posição ordinal. Um valor de array é representado como uma série de elementos refletindo a matriz, com membros aparecendo em sequência ordinal ascendente. Para arrays multidimensionais, a dimensão do lado direito varia mais rapidamente. Cada elemento-membro é nomeado como um elemento independente. Um serviço web que espera um array pode ser o alvo de um ataque XML DoS, forçando o servidor SOAP a construir um array enorme na memória da máquina, infligindo assim uma condição DoS na máquina devido à pré-alocação de memória.</desc>
	<solution> Execute a validação de entrada adequada contra qualquer valor que influencie a quantidade de memória alocada. Defina uma estratégia adequada para o tratamento de solicitações que excedem o limite e considere apoiar uma opção de configuração para que o administrador possa estender a quantidade de memória a ser usada, se necessário.

Execute o programa usando os limites de memória fornecidos pelo sistema. Isso ainda pode ocasionar no travamento ou fechamento do programa, mas o impacto para o resto do sistema será minimizado.</solution>
	<reference>http://projects.webappsec.org/SOAP-Array-Abuse</reference>
	<reference>http://cwe.mitre.org/data/definitions/789.html</reference>
</vuln_item_wasc_35>

<vuln_items>wasc_36</vuln_items>
<vuln_item_wasc_36>
	<alert>Injeção SSI</alert>
	<desc>SSI Injection (Server-Side Include) é uma técnica de exploração do lado do servidor que permite a um invasor enviar código para uma aplicação web, que mais tarde será executado localmente pelo servidor da web. A SSI Injection explora a falha de uma aplicação web em higienizar os dados fornecidos pelo usuário antes que eles sejam inseridos em um arquivo HTML interpretado do lado do servidor.

Antes de servir uma página da web em HTML, um servidor da web pode analisar e executar instruções de inclusão do lado do servidor antes de fornecê-la ao cliente. Em alguns casos (por exemplo, painéis de mensagens, livros de visitas ou sistemas de gerenciamento de conteúdo), uma aplicação web irá inserir dados fornecidos pelo usuário no código-fonte de uma página web.

Se um invasor enviar uma instrução de inclusão do lado do servidor, ele poderá executar comandos arbitrários de sistema operacional ou incluir o conteúdo de um arquivo restrito na próxima vez que a página for exibida. Isso é executado no nível de permissão do usuário do servidor web.</desc>
	<solution>Desabilite a execução do SSI em páginas que não exigem isso. 
Para páginas que requerem SSI, certifique-se de realizar as seguintes verificações:
* - Habilite apenas as diretivas SSI necessárias para esta página e desabilite todas as outras;

* - Codifique na entidade HTML, os dados fornecidos pelo usuário antes de passá-los para uma página com permissões de execução SSI;

* - Use SUExec para que a página seja executada como a proprietária do arquivo, ao invés do usuário do servidor web.</solution>
	<reference>http://projects.webappsec.org/SSI-Injection</reference>
	<reference/>
</vuln_item_wasc_36>

<vuln_items>wasc_37</vuln_items>
<vuln_item_wasc_37>
	<alert>Fixação de Seção</alert>
	<desc>A Fixação de Sessão é uma técnica de ataque que força o ID de sessão de um usuário a se tornar um valor explícito. Dependendo da funcionalidade do site de destino, várias técnicas podem ser utilizadas para "fixar" o valor do ID da sessão. Essas técnicas variam de exploits de Cross-site Scripting (XSS) a bombardear o site com solicitações HTTP feitas anteriormente. Depois que o ID de sessão de um usuário for fixado, o invasor esperará que esse usuário faça o login. Depois que o usuário faz isso, o invasor usa o valor de ID de sessão predefinido para assumir a mesma identidade online.

De um modo geral, existem dois tipos de sistemas de gerenciamento de sessão quando se trata de valores de ID. O primeiro tipo são os sistemas "permissivos" que permitem que os navegadores da web especifiquem qualquer ID. O segundo tipo são sistemas "estritos" que aceitam apenas valores gerados no lado do servidor. Com sistemas permissivos, IDs de sessão arbitrários são mantidos sem contato com o site. Sistemas estritos (rígidos) exigem que o invasor mantenha a "trap-session", com contato periódico com o site, evitando tempos limite de inatividade (timeouts).

Sem proteção ativa contra a Fixação de Sessão, o ataque pode ser montado contra qualquer site da web que usa sessões para identificar usuários autenticados. Os sites que usam IDs de sessão normalmente são baseados em cookies, mas URLs e campos de formulário ocultos também são usados. Infelizmente, as sessões baseadas em cookies são as mais fáceis de atacar. A maioria dos métodos de ataque identificados atualmente são direcionados à fixação de cookies.

Em contraste com o roubo dos IDs de sessão de um usuário depois que ele se conecta a um site, o Session Fixation oferece uma janela de oportunidade muito mais ampla. A parte ativa do ataque ocorre antes de um usuário efetuar login.</desc>
	<solution>Invalide quaisquer identificadores de sessão existentes antes de autorizar uma nova sessão de usuário.
Para plataformas como ASP que não geram novos valores para cookies de sessão, use um cookie secundário. Nessa abordagem, defina um cookie secundário no navegador do usuário com um valor aleatório e defina uma variável de sessão com o mesmo valor. Se a variável de sessão e o valor do cookie não corresponderem, invalide a sessão e force o usuário a fazer logon novamente.</solution>
	<reference>http://projects.webappsec.org/Session-Fixation</reference>
	<reference>http://cwe.mitre.org/data/definitions/384.html</reference>
</vuln_item_wasc_37>

<vuln_items>wasc_38</vuln_items>
<vuln_item_wasc_38>
	<alert>Violação de Redirecionador de URL</alert>
	<desc>Os redirecionadores de URL representam uma funcionalidade comum empregada por sites para encaminhar uma solicitação de entrada a um recurso alternativo. Isso pode ser feito por vários motivos e geralmente é feito para permitir que os recursos sejam movidos dentro da estrutura de diretório e para evitar a interrupção da funcionalidade para usuários que solicitam o recurso em seu local anterior. Os redirecionadores de URL também podem ser usados para implementar balanceamento de carga, aproveitando URLs abreviadas ou registrando links de saída. É esta última implementação que costuma ser usada em ataques de phishing, conforme descrito no exemplo abaixo. Os redirecionadores de URL não representam necessariamente uma vulnerabilidade de segurança direta, mas podem ser violados por invasores que tentam fazer com que as vítimas acreditem que estão navegando para um site diferente do destino verdadeiro.</desc>
	<solution>Presuma que toda a entrada de dados é maliciosa. Use uma estratégia de validação de entrada "aceita como boa", ou seja, use uma lista de permissões de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite quaisquer entradas que não estejam estritamente de acordo com as especificações ou transforme-as em algo que esteja. Não confie exclusivamente na procura de entradas maliciosas ou malformadas (ou seja, não confie em uma lista de negação). No entanto, as listas de negação podem ser úteis para detectar ataques em potencial ou determinar quais entradas estão tão malformadas que devem ser rejeitadas imediatamente.

Ao executar a validação de entradas de dados, considere todas as propriedades potencialmente relevantes, incluindo comprimento, tipo de entrada, a gama completa de valores aceitáveis, entradas ausentes ou extras, sintaxe, consistência entre campos relacionados e conformidade com as regras de negócios. Como um exemplo de lógica de regra de negócios, "barco" pode ser sintaticamente válido porque contém apenas caracteres alfanuméricos, mas não é válido se você estiver esperando cores como "vermelho" ou "azul".

Use uma lista de permissão de URLs ou domínios aprovados a serem usados para redirecionamento.

Use uma página de isenção de responsabilidade intermediária que forneça ao usuário um aviso claro de que ele está deixando seu site. Implemente um longo tempo limite (timeout) antes que ocorra o redirecionamento ou force o usuário a clicar no link. Tenha cuidado para evitar problemas de XSS ao gerar a página de isenção de responsabilidade.

Havendo um conjunto de objetos aceitáveis, limitados ou conhecidos como nomes de arquivos ou URLs, crie um mapeamento de um conjunto de valores de entrada fixos (como IDs numéricos) para os nomes de arquivos ou URLs reais e rejeite quaisquer outras entradas.

Por exemplo, o ID 1 pode ser mapeado para "/login.asp" e o ID 2 pode ser mapeado para "http://www.example.com/". Recursos como o ESAPI AccessReferenceMap fornecem esse recurso.

Compreenda todas as potenciais áreas onde entradas de dados não confiáveis podem ser inseridas em seu software: parâmetros ou argumentos, cookies, qualquer coisa lida a partir da rede, variáveis de ambiente, pesquisas de DNS reverso, resultados de consultas, cabeçalhos de solicitações, componentes de URLs, e-mails, arquivos, bancos de dados e quaisquer sistemas externos que forneçam dados para a aplicação. Lembre-se de que essas entradas podem ser obtidas indiretamente por meio de chamadas de API.

Muitos problemas de redirecionamento aberto ocorrem porque o desenvolvedor presumiu que certas entradas não poderiam ser modificadas, como cookies e campos de formulário ocultos.</solution>
	<reference>http://projects.webappsec.org/URL-Redirector-Abuse</reference>
	<reference>http://cwe.mitre.org/data/definitions/601.html</reference>
</vuln_item_wasc_38>

<vuln_items>wasc_39</vuln_items>
<vuln_item_wasc_39>
	<alert>Injeção XPath</alert>
	<desc>Injeção XPath (XPath Injection) é uma técnica de ataque usada para explorar aplicações que constroem consultas XPath (XML Path Language) de entrada fornecida pelo usuário para consultar ou navegar em documentos XML. Ela pode ser usada diretamente por uma aplicação para consultar um documento XML, como parte de uma operação maior, como aplicar uma transformação XSLT a um documento XML ou aplicar uma XQuery a um documento XML. A sintaxe do XPath tem alguma semelhança com uma consulta SQL e, de fato, é possível formar consultas semelhantes a SQL em um documento XML usando XPath.

Se um aplicativo usa construção de consulta XPath em tempo de execução, incorporando entrada não segura do usuário na consulta, pode ser possível para o invasor injetar dados na consulta de forma que a consulta recém-formada seja analisada de uma forma diferente da intenção do desenvolvedor.</desc>
	<solution>Use consultas XPath parametrizadas (por exemplo, usando XQuery). Isso ajudará a garantir a separação entre o plano de dados e o plano de controle.

Valide adequadamente as entradas do usuário. Rejeite dados quando apropriado, filtre quando apropriado e escape quando apropriado. Certifique-se de que a entrada que será usada nas consultas XPath seja segura nesse contexto.</solution>
	<reference>http://projects.webappsec.org/XPath-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/643.html</reference>
</vuln_item_wasc_39>

<vuln_items>wasc_40</vuln_items>
<vuln_item_wasc_40>
	<alert>Validação Insuficiente de Processo</alert>
	<desc>A Validação Insuficiente de Processo ocorre quando uma aplicação web falha em impedir que um invasor contorne o fluxo pretendido ou a lógica de negócios do aplicativo. Quando vista no mundo real, a validação insuficiente de processo resulta em controles de acesso ineficazes e perda monetária.

Existem dois tipos principais de processos que requerem validação: controle de fluxo e lógica de negócios.

"Controle de fluxo" refere-se a processos de várias etapas que exigem que cada etapa seja realizada em uma ordem específica pelo usuário. Quando um invasor executa a etapa incorretamente ou fora de ordem, os controles de acesso podem ser ignorados e pode ocorrer um erro de integridade do aplicativo. Exemplos de processos de várias etapas incluem transferência eletrônica, recuperação de senha, finalização da compra e inscrição na conta.

"Lógica de negócios" se refere ao contexto no qual um processo será executado conforme regido pelos requisitos de negócios. Explorar uma fraqueza da lógica de negócios requer conhecimento do negócio; se nenhum conhecimento é necessário para explorá-lo, provavelmente não é uma falha de lógica de negócios. Devido a isso, medidas de segurança típicas, como varreduras e revisão de código, não encontrarão essa classe de fraqueza. Uma abordagem de teste é oferecida pelo OWASP em seu Guia de Teste.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Process-Validation</reference>
	<reference/>
</vuln_item_wasc_40>

<vuln_items>wasc_41</vuln_items>
<vuln_item_wasc_41>
	<alert>Explosão de Atributo XML</alert>
	<desc>Explosão de Atributo XML (XML Attribute Blowup) é um ataque de negação de serviço (DoS) contra analisadores XML. O invasor fornece um documento XML malicioso, que os analisadores XML vulneráveis processam de maneira muito ineficiente, levando a uma carga excessiva da CPU. A essência do ataque é incluir muitos atributos no mesmo nó XML. Analisadores XML vulneráveis gerenciam os atributos de uma maneira ineficiente (por exemplo, em um contêiner de dados para o qual a inserção de um novo atributo tem tempo de execução O (n)), resultando em um não linear (neste exemplo, quadrático, ou seja, O (n2)) tempo de execução geral, levando a uma condição de negação de serviço por meio do esgotamento da CPU.</desc>
	<solution>Projete mecanismos de limitação na arquitetura do sistema. A melhor proteção é limitar a quantidade de recursos que um usuário não autorizado pode fazer com que sejam gastos. Um modelo de autenticação forte e controle de acesso ajudará a evitar que tais ataques ocorram em primeiro lugar. O aplicativo de login deve ser protegido contra ataques DoS tanto quanto possível. Limitar o acesso ao banco de dados por exemplo armazenando conjuntos de resultados em cache, pode ajudar a minimizar os recursos gastos. Para limitar ainda mais o potencial de um ataque DoS, considere rastrear a taxa de solicitações recebidas de usuários e bloquear solicitações que excedam um limite de taxa definido.


A mitigação de ataques de exaustão de recursos requer que o sistema alvo:
* - Reconheça o ataque e negue a esse usuário acesso adicional por um determinado período de tempo, ou
* - Limite uniformemente todas as solicitações para tornar mais difícil consumir recursos mais rapidamente do que eles podem ser liberados novamente. 


A primeira dessas soluções é um problema em si, pois pode permitir que invasores impeçam o uso do sistema por um determinado usuário válido. Se o invasor se passar por um usuário válido, ele poderá impedir que o usuário acesse o servidor em questão.


A segunda solução é simplesmente difícil de implementar com eficácia - e mesmo quando feita de maneira adequada, não oferece uma solução completa. Isso simplesmente faz com que o ataque exija mais recursos por parte do invasor.

Certifique-se de que os protocolos têm limites específicos de escala colocados neles.

Certifique-se de que todas as falhas na alocação de recursos não colocam o sistema em uma posição insegura.</solution>
	<reference>http://projects.webappsec.org/XML-Attribute-Blowup</reference>
	<reference>http://cwe.mitre.org/data/definitions/400.html</reference>
</vuln_item_wasc_41>

<vuln_items>wasc_42</vuln_items>
<vuln_item_wasc_42>
	<alert>Violação de Funcionalidades</alert>
	<desc>Violação de Funcionalidades é uma técnica de ataque que usa os próprios recursos e funcionalidades de um site da web para atacar a si mesmo ou a terceiros. Violação de funcionalidades pode ser descrito como o abuso da funcionalidade pretendida de uma aplicação para realizar um resultado indesejável. Esses ataques têm resultados variados, como consumir recursos, burlar controles de acesso ou vazar informações. O potencial e o nível de abuso variam de site para site e de aplicação para aplicação. Os ataques de violação de funcionalidade são geralmente uma combinação de outros tipos de ataque e/ou utilizam outros vetores de ataque.</desc>
	<solution>Sempre utilize APIs da maneira especificada.</solution>
	<reference>http://projects.webappsec.org/Abuse-of-Functionality</reference>
	<reference>http://cwe.mitre.org/data/definitions/227.html</reference>
</vuln_item_wasc_42>

<vuln_items>wasc_43</vuln_items>
<vuln_item_wasc_43>
	<alert>Entidades Externas XML</alert>
	<desc>Essa técnica aproveita um recurso do XML para construir documentos dinamicamente no momento do processamento. Uma mensagem XML pode fornecer dados explicitamente ou apontando para um URI onde os dados existem. Na técnica de ataque, entidades externas podem substituir o valor da entidade por dados maliciosos, referências alternativas ou podem comprometer a segurança dos dados aos quais o servidor/aplicativo XML tem acesso.
	Os invasores também podem usar Entidades Externas para que o servidor de serviços da web baixe código malicioso ou conteúdo para o servidor para uso em ataques secundários ou acompanhamento.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/XML-External-Entities</reference>
	<reference/>
</vuln_item_wasc_43>

<vuln_items>wasc_44</vuln_items>
<vuln_item_wasc_44>
	<alert>Expansão de Entidade XML</alert>
	<desc>O ataque de Expansão de Entidade XML explora um recurso em XML DTDs que permite a criação de macros personalizadas, chamadas de entidades, que podem ser usadas em todo o documento. Ao definir recursivamente um conjunto de entidades personalizadas na parte superior de um documento, um invasor pode sobrecarregar os analisadores que tentam resolver completamente as entidades, forçando-os a iterar quase indefinidamente nessas definições recursivas.

A mensagem XML maliciosa é usada para forçar a expansão recursiva da entidade (ou outro processamento repetido) que usa completamente os recursos disponíveis do servidor.</desc>
	<solution>Se possível, proíba o uso de DTDs ou use um analisador XML que limite a expansão de entidades DTD recursivas.

Antes de analisar arquivos XML com DTDs associados, verifique as declarações de entidade recursiva e não continue analisando conteúdo potencialmente explosivo.</solution>
	<reference>http://projects.webappsec.org/XML-Entity-Expansion</reference>
	<reference>http://cwe.mitre.org/data/definitions/776.html</reference>
</vuln_item_wasc_44>

<vuln_items>wasc_45</vuln_items>
<vuln_item_wasc_45>
	<alert>Fingerprinting</alert>
	<desc>A metodologia mais comum para invasores é primeiro rastrear a presença do alvo na web e enumerar o máximo de informações possível. Com essas informações, o invasor pode desenvolver um cenário de ataque preciso, que explorará com eficácia uma vulnerabilidade no tipo/versão do software que está sendo utilizado pelo host de destino.

O fingerprinting multicamadas é semelhante a seu antecessor, TCP/IP fingerprinting (com um scanner como o Nmap), exceto que ela é focada na Camada de Aplicação do modelo OSI em vez da Camada de Transporte. A teoria por trás do fingerprinting é criar um perfil preciso da plataforma de destino, tecnologia de software de aplicativo da web, versão do banco de dados de backend, configurações e possivelmente até mesmo sua arquitetura/topologia de rede.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Fingerprinting</reference>
	<reference/>
</vuln_item_wasc_45>

<vuln_items>wasc_46</vuln_items>
<vuln_item_wasc_46>
	<alert>Injeção XQuery</alert>
	<desc>Injeção XQuery (XQuery Injection) é uma variante do clássico ataque de Injeção SQL contra a linguagem XML XQuery. Injeção XQuery usa dados validados incorretamente que são passados para comandos XQuery. Isso, por sua vez, executará comandos em nome do invasor ao qual as rotinas XQuery têm acesso. A Injeção XQuery pode ser usada para enumerar elementos no ambiente da vítima, injetar comandos no host local ou executar consultas em arquivos remotos e fontes de dados. Assim como os ataques de Injeção SQL, o invasor faz um túnel através do ponto de entrada da aplicação para atingir a camada de acesso ao recurso.</desc>
	<solution>Use consultas parametrizadas. Isso ajudará a garantir a separação entre o plano de dados e o plano de controle.

Valide adequadamente as entradas do usuário. Rejeite dados quando apropriado, filtre quando apropriado e escape quando apropriado. Certifique-se de que a entrada que será usada nas consultas XQL seja segura nesse contexto.</solution>
	<reference>http://projects.webappsec.org/XQuery-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/652.html</reference>
</vuln_item_wasc_46>

<vuln_items>wasc_47</vuln_items>
<vuln_item_wasc_47>
	<alert>Expiração de Sessão Insuficiente</alert>
	<desc>A Expiração de Sessão Insuficiente ocorre quando uma aplicação web permite que um invasor reutilize credenciais de sessão ou IDs de sessão antigos para autorização. A expiração de sessão insuficiente aumenta a exposição de um site a ataques que roubam ou reutilizam os identificadores de sessão do usuário.

Como o HTTP é um protocolo sem estado, os sites normalmente usam cookies para armazenar IDs de sessão que identificam exclusivamente um usuário de solicitação a solicitação. Conseqüentemente, a confidencialidade de cada ID de sessão deve ser mantida para evitar que vários usuários acessem a mesma conta. Um ID de sessão roubado pode ser usado para visualizar a conta de outro usuário ou realizar uma transação fraudulenta.

A expiração da sessão é composta por dois tipos de tempo limite: inatividade e absoluto. Um tempo limite absoluto é definido pela quantidade total de tempo que uma sessão pode ser válida sem reautenticação e um tempo limite de inatividade é a quantidade de tempo ocioso permitido antes que a sessão seja invalidada. A falta de expiração adequada da sessão pode aumentar a probabilidade de sucesso de certos ataques. Um tempo de expiração muito longo aumenta a chance de um invasor adivinhar com sucesso uma ID de sessão válida. Quanto mais longo for o tempo de expiração, mais sessões abertas simultâneas existirão a qualquer momento. Quanto maior o pool de sessões, maior será a probabilidade de um invasor adivinhar uma aleatoriamente. Embora um tempo limite de inatividade de sessão curto não ajude se um token for usado imediatamente, o tempo limite curto ajuda a garantir que o token seja mais difícil de capturar enquanto ainda for válido.

Uma aplicação web deve invalidar uma sessão após um tempo ocioso predefinido ter passado (um tempo limite) e fornecer ao usuário os meios para invalidar sua própria sessão, ou seja, logoff; isso ajuda a manter a vida útil de um ID de sessão o mais curto possível e é necessário em um ambiente de computação compartilhado, onde mais de uma pessoa tem acesso físico irrestrito a um computador. A função de logout deve ser bem visível para o usuário, invalidar explicitamente a sessão de um usuário e proibir a reutilização do token de sessão.</desc>
	<solution>Defina o tempo de expiração das sessões/credenciais.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Session-Expiration</reference>
	<reference>http://cwe.mitre.org/data/definitions/613.html</reference>
</vuln_item_wasc_47>

<vuln_items>wasc_48</vuln_items>
<vuln_item_wasc_48>
	<alert>Indexação Insegura</alert>
	<desc>A indexação insegura é uma ameaça à confidencialidade dos dados do site. A indexação de conteúdo de um site por meio de um processo que tem acesso a arquivos que não deveriam ser publicamente acessíveis tem o potencial de vazar informações sobre a existência de tais arquivos e sobre seu conteúdo. No processo de indexação, tais informações são coletadas e armazenadas pelo processo de indexação, que pode ser posteriormente recuperado (embora não trivialmente) por um determinado invasor, normalmente por meio de uma série de consultas ao mecanismo de busca. O invasor não impede o modelo de segurança do mecanismo de pesquisa. Como tal, este ataque é sutil e muito difícil de detectar e frustrar - não é fácil distinguir as consultas do invasor das consultas de um usuário legítimo.</desc>
	<solution>Uma solução será disponibilizada em breve.</solution>
	<reference>http://projects.webappsec.org/Insecure-Indexing</reference>
	<reference/>
</vuln_item_wasc_48>

<vuln_items>wasc_49</vuln_items>
<vuln_item_wasc_49>
	<alert>Recuperação de Senha Insuficiente</alert>
	<desc>A recuperação de senha insuficiente ocorre quando um site permite que um invasor obtenha, altere ou recupere ilegalmente a senha de outro usuário. Os métodos convencionais de autenticação de sites exigem que os usuários selecionem e lembrem uma senha ou frase secreta. O usuário deve ser a única pessoa a conhecer a senha e a mesma deve ser lembrada com precisão. Com o passar do tempo, a capacidade do usuário de lembrar uma senha diminui. A questão fica ainda mais complicada quando o usuário médio visita 20 sites, exigindo que forneçam uma senha.  (Pesquisa RSA: http://news.bbc.co.uk/1/hi/technology/3639679.stm)
Portanto, a recuperação de senha é uma parte importante no atendimento aos usuários online.

Exemplos de processos automatizados de recuperação de senha incluem exigir que o usuário responda a uma "pergunta secreta" definida como parte do processo de registro do usuário. Esta pergunta pode ser selecionada em uma lista de perguntas prontas ou fornecida pelo usuário. Outro mecanismo em uso é fazer com que o usuário forneça uma "dica" durante o registro que o ajudará a lembrar sua senha. Outros mecanismos exigem que o usuário forneça vários dados pessoais, como seu número de segurança social, endereço residencial, código postal, etc. para validar sua identidade. Depois que o usuário provar quem é, o sistema de recuperação exibirá ou enviará a ele uma nova senha por e-mail.

Um site é considerado como tendo recuperação de senha insuficiente quando um invasor consegue impedir o mecanismo de recuperação que está sendo usado. Isso acontece quando as informações necessárias para validar a identidade de um usuário para recuperação são facilmente adivinhadas ou podem ser contornadas. Os sistemas de recuperação de senha podem ser comprometidos pelo uso de ataques de força bruta, fraquezas inerentes do sistema ou perguntas secretas facilmente adivinhadas.</desc>
	<solution>Certifique-se de que todas as entradas fornecidas pelo usuário para o mecanismo de recuperação de senha sejam completamente filtradas e validadas
Não use perguntas de segurança fracas padrão e use várias perguntas de segurança.

Certifique-se de que haja limitação no número de respostas incorretas a uma pergunta de segurança. Desative a funcionalidade de recuperação de senha após um determinado (pequeno) número de suposições incorretas.

Exija que o usuário responda adequadamente à pergunta de segurança antes de redefinir sua senha e enviar a nova senha para o endereço de e-mail registrado.

Nunca permita que o usuário controle para qual endereço de e-mail a nova senha será enviada no mecanismo de recuperação de senha.

Atribua uma nova senha temporária ao invés de revelar a senha original.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Password-Recovery</reference>
	<reference>http://cwe.mitre.org/data/definitions/640.html</reference>
</vuln_item_wasc_49>

</vulnerabilities>
